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ABSTRACT 


Deployed  operations  necessitate  Department  of  Defense  forces  to  operate  in 
remote  and  sparsely  connected  locations  that  limit  their  ability  to  maintain  high-quality, 
high-speed  visual  communications  with  the  rest  of  the  force.  An  operational  requirement 
has  been  established  for  the  provision  of  video  services  that  can  swiftly  distribute  high- 
quality  video  from  within  the  fleet  to  anywhere  in  the  world  with  short  notice.  Such  a 
capability  requires  rapidly  deployable,  high-throughput,  low-latency  satellite 
communications.  Modem  satellite  constellations  can  enable  this  capability  acting  as  a 
high-speed  telecommunications  portal. 

This  research  evaluated  an  integrated,  satellite-enabled,  high  definition  portable 
video  processing  solution  constructed  from  commercially  available  components.  This 
solution  can  be  used  to  deliver  ultra  high  definition  (UHD)  video  from  forward-deployed 
units  in  a  wide  variety  of  use  cases  and  applications.  The  use  case  developed  in  this 
research  utilized  commodity  digital  camera  and  computing  equipment  to  send  a  live  4K 
video  stream  to  the  Defense  Media  Activity’s  public  video  media  outlet,  DVIDS. 

This  quantitative  experimental  research  found  that  the  03b  Networks  Medium 
Earth  Orbit  satellite  terminal  successfully  provided  sufficient  bandwidth  and  acceptable 
latency  to  provide  network  services  for  forward-deployed  UHD  video  devices. 
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EXECUTIVE  SUMMARY 


On-location  Public  Affairs  Reach-back  System  (OnPARS)  provides  live  ultra 
high  definition  video  streams  from  locations  with  limited  data  infrastructure  via  emerging 
satellite  systems  that  provide  “fiber-like”  speed. 

Introduction 

The  OnPARS  is  a  portable  video  server  integrated  with  a  high-speed  satellite 
terminal  to  facilitate  the  creation,  processing,  and  transmission  of  high-quality  video  from 
a  remote  location.  It  is  the  product  of  student  research  efforts  at  the  Naval  Postgraduate 
School  (NPS)  and  sponsored  by  the  Office  of  Naval  Research  (ONR)  Technology 
Solutions. 

Problem  Statement 

Deployed  operations  take  Department  of  Defense  (DOD)  forces  to  remote, 
sparsely  connected  locations  that  cut  off  their  ability  to  maintain  high-quality,  high-speed 
visual  communications  with  the  rest  of  the  force.  An  operational  need  exists  to  provide 
ultra  high  definition  (UHD)  video  from  forward-deployed  units  in  remote  operating  areas 
using  state-of-the-art  commercial  video  capture  and  encoding  technologies.  Modern 
satellite  constellations  offer  a  portal  back  via  high-speed  telecommunications. 

To  address  the  problem,  a  high-throughput/low-delay,  portable,  medium  Earth 
orbit  (MEO)  satellite  system  was  selected  to  provide  network  connectivity  for  a  video 
server.  Previous  research  (Stephens  &  Adams,  2016)  tested  a  portable  video  processing 
system  and  the  performance  of  an  MEO  satellite  system  separately.  The  previous 
research  concluded  that  the  MEO  satellite  system  that  operates  on  the  commercial 
provider  03b’s  satellite  constellation  provided  sufficient  bandwidth  for  transmitting  high 
definition  video  in  real  time.  It  was  also  concluded  that  the  NPS  video  cloud  server, 
through  its  installed  viaPlatz  software,  provided  the  processing  capability  required  to 
prepare  digital  high  definition  video  for  transmission  over  the  03b  connection. 

This  research  effort  sought  to  integrate  the  previously  recommended  systems  to 
provide  the  capability  to  transmit  UHD  video  from  a  remote  location  where 
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telecommunications  infrastructure  may  be  limited  or  damaged.  Live  UHD  video 
streaming  was  demonstrated  and  provides  data  and  a  model  for  further  development  of 
the  capabilities  required  by  DOD  forces. 

Methods 

viaPlatz  provides  the  ability  to  ingest  and  manage  a  collection  of  digital  video 
files.  It  also  provides  the  capability  to  provide  that  video  to  consumers  (i.e.,  higher 
headquarters,  DOD  forces,  etc.)  via  a  local  login  system.  Consumers  of  the  video  must 
have  an  account  on  the  local  viaPlatz  server  and  login  to  that  specific  server.  To  prevent 
disruption  of  service  due  to  movement  of  the  terminal  or  degradation  of  the  satellite 
connection,  a  partner  viaPlatz  server  was  installed  and  configured  in  the  NPS  data  center 
(see  Figure  1). 


DVIDS 


Figure  1.  OnPARS  System  Diagram 


Consultation  with  the  producer  of  viaPlatz,  NTT  IT  Corporation,  revealed  that  the 
installed  version  of  viaPlatz  was  not  capable  of  performing  in  a  partnered  configuration 
outside  of  a  local  area  network  (LAN).  The  theory  was  to  ingest  video  on  a  remote 
viaPlatz  server  collocated  with  the  satellite  terminal.  The  video  would  then  be  transmitted 
over  the  satellite  link  to  a  stationary  server  in  a  data  center.  The  video  would  then  be 
stored  and  distributed  from  the  stationary  server.  NTT  IT  Corporation  suggested  that  a 
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newer  version  of  the  software  could  provide  this  capability.  The  upgrade  to  viaPlatz 
version  3.0  is  pending. 

To  test  the  video  streaming  capacity  of  the  integrated  server  and  satellite  terminal 
solution,  alternative  software  was  selected,  installed,  and  tested.  A  custom  build  of 
FFmpeg  was  installed  on  the  mobile  server  to  enable  the  capture  of  live  video.  A  custom 
build  of  NGINX,  an  open  source  web  server,  was  installed  on  the  stationary  server  in  the 
data  center  to  receive  and  retransmit  live  video. 

03b  Networks  operates  an  MEO  satellite  constellation  with  the  advertised 
capacity  to  provide  800Mbps  of  bandwidth  in  each  direction,  for  a  total  throughput  of 
1.6Gbps,  per  beam  (03b  Networks,  n.d.).  The  MEO  satellite  terminal  purchased  from 
SES  Government  Solutions  consisted  of  commercial  off-the-shelf  (COTS)  components, 
including  two  85cm  automatically  tracking  antenna  assemblies  (satellite  dishes).  The 
advertised  bandwidth  of  the  system  equipped  with  85cm  antennas  is  100Mbps  upload  and 
300Mbps  download,  with  potential  upload  speeds  of  130Mbps  in  a  highly  optimized 
configuration  (SES  Government  Solutions,  2016). 

03b’s  MEO  constellation  also  provides  low-latency  speeds  that  are  desirable  for 
use  in  video  applications.  Advertised  latency  of  120ms  is  achieved  through  a  relatively 
closer  satellite  orbit.  Where  geosynchronous  Earth  orbit  (GEO)  satellites  occupy  a  fixed 
relative  location  above  the  Earth  at  a  distance  of  approximately  22,000  miles,  03b’ s 
MEO  satellites  orbit  at  a  distance  of  approximately  5,000  miles  (SES  Government 
Solution,  2016). 
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Figure  2.  Gravitational  and  Centrifugal  Forces  Acting  on  Satellites  Orbiting  Earth. 

Source:  Maini  &  Agrawal  (2014). 


Unlike  GEO  satellite  systems,  MEO  satellite  systems  require  an  orbiting 
constellation  of  multiple  satellites  to  provide  continuous  coverage  over  a  given  terrestrial 
location.  Kepler’s  laws  of  planetary  motion  as  well  as  Newton’s  law  of  gravitation 
explain  how  satellites  maintain  their  orbits  around  the  Earth.  GEO  satellites  maintain  an 
orbit  speed  that  is  synchronized  with  the  Earth’s  rotation  by  maintaining  a  position 
further  away  from  the  Earth.  The  satellite’s  distance  (R  in  Figure  2)  from  Earth  is 
adjusted  so  that  the  resultant  velocity  (v)  matches  the  Earth’s  rotational  speed,  allowing 
the  satellite  to  maintain  its  relative  position  over  the  Earth. 

MEO  satellite  systems  reduce  the  amount  of  time  a  signal  must  travel  by 
decreasing  the  physical  distance  between  the  satellite  and  Earth.  When  the  distance  (R)  is 
reduced,  the  gravitational  force  increases,  also  increasing  the  centrifugal  force  on  the 
satellite,  which  also  increases  the  resultant  velocity  (v).  The  result  is  a  perceived  rising 
and  setting  of  a  given  satellite  when  observed  from  a  fixed  spot  on  the  Earth,  requiring 
the  ground  terminal  to  track  the  relative  movement  of  the  satellite.  Before  one  satellite 
orbits  below  the  horizon,  the  next  satellite  has  risen  into  view.  The  dual,  automatically 
tracking  antennas  provide  a  seamless  transition  from  the  setting  satellite  to  the  rising 
satellite  (see  Figure  3). 
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03b  MEO  Satellite  Handover  Process 
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This  figure  was  adapted  from  03b  Networks  training  materials  (A.  Jones,  personal 
communication,  08  September  2016). 


Figure  3.  03b  MEO  Satellite  Handover  Process 
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OnPARS  was  transported  from  NPS  to  Camp  Roberts,  California,  to  test  the 
integrated  solution  in  a  field-representative  environment.  The  entire  assembly  consisted 
of  eight  two-person  transportable  containers  that  housed  the  equipment  and  protected  it 
during  transport.  Seven  containers  made  up  the  satellite  terminal,  not  including  spare 
parts,  and  one  container  for  the  video  server.  Also  required  was  a  compatible  camera 
capable  of  capturing  UHD  video. 

Several  tests  were  conducted  at  Camp  Roberts  to  capture  data  on  network  and 
streaming  video  performance.  Standard  network  performance  tools  (Ping  and  iPerf)  were 
used  to  test  latency,  jitter,  and  bandwidth.  Another  standard  network  tool,  IPTraf,  was 
used  to  capture  the  amount  of  data  leaving  the  video  server  while  it  was  streaming  video. 
UHD  video  was  streamed  to  the  server  in  the  data  center  at  NPS  and  to  the  Defense 
Video  and  Image  Distribution  System  (DVIDS)  in  Georgia. 

Finally,  the  system  was  demonstrated  to  an  ONR  TechSolutions  representative  at 
an  SES  facility  in  Manassas,  Virginia.  No  testing  data  was  collected  during  the 
demonstration,  but  observed  performance  was  similar  to  that  of  the  Camp  Roberts  tests. 

Conclusions 

viaPlatz  2.0  did  not  provide  the  desired  functionality  and  was  not  tested  with  the 
03b  MEO  satellite  terminal.  viaPlatz  2.0  could  ingest  and  manage  the  media,  but  would 
not  work  with  a  partner  server  over  the  satellite  connection.  Therefore,  viaPlatz  was  not 
tested  during  this  research. 

FFmpeg  was  chosen  to  provide  the  capability  to  stream  to  UHD  video  from  the 
video  server.  While  functional,  this  solution  was  inelegant  and  ill-suited  for  routine  use. 
FFmpeg  is  a  command-line  program  with  numerous  options  that  may  prove  difficult  to 
use  for  the  intended  users. 

The  satellite  terminal  as  configured  provided  60-70Mbps  of  bandwidth  in  each 
direction.  This  throughput  was  less  than  advertised,  but  proved  sufficient  for  UHD 
streaming.  The  live  UHD  stream  consumed  an  average  of  0.6  to  1.1  Mbps  of  bandwidth 
during  transmission  as  measured  by  the  IPTraf  network  adapter  monitoring  tool.  An 
average  of  160ms  round-trip  time  (RTT)  was  observed  during  network  performance 
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testing.  03b  technicians  explained  that  the  terminal  requires  optimization  upon  setup  at  a 
new  location  to  achieve  the  higher  advertised  performance. 

Recommendations 

Upgrade  the  portable  and  stationary  servers  to  viaPlatz  3.0.  NTT  IT 

Corporation  suggested  that  the  desired  two-server  configuration  could  work  with  the 
newer  version  of  their  software.  Adobe  Media  Server  (AMS),  a  standard  industry  media 
server  solution,  is  an  integral  component  of  viaPlatz  and  could  provide  the  desired 
streaming  functionality  independent  of  the  viaPlatz  functionality. 

Research  other  COTS  video-streaming  software  solutions.  FFmpeg  is  a 
versatile  open  source  product  that  has  been  integrated  into  many  other  projects.  A  more 
user-friendly  graphical  user  interface  (GUI)-based  solution  should  be  sought  to  provide  a 
reliable  and  easy  to  use  product  for  deployed  forces.  This  could  have  an  impact  on  the 
annual  maintenance  costs  for  the  servers. 

Collaborate  with  DVIDS  to  realize  an  optimized  video-streaming  solution. 

DVIDS  currently  deploys  a  video  server  that  provides  lower  resolution  video  streams  to 
its  content  delivery  network  (CDN).  Assistance  from  DVIDS  should  be  sought  to 
optimize  the  FFmpeg  solution  or  select  more  user-friendly  software  to  initiate  and 
manage  the  video  stream. 
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XXIV 


I. 


INTRODUCTION 


A.  PROBLEM  AREA 

An  operational  need  exists  to  provide  high  definition  video  to  and  from  forward- 
deployed  units  in  remote  operating  areas.  This  capability  requires  the  use  of  state-of-the- 
art  commercial  video  capture  and  encoding  technologies  over  emerging  extremely  high 
data  rate  satellite  communication  links. 

This  research  effort  integrated  an  advanced  digital  video  capability  with  an 
emerging  commercial  broadband  satellite  capability,  as  proposed  by  a  previous  thesis. 
Performance  and  capabilities  of  the  integrated  system  were  validated  by  a  series  of  field 
experiments  and  demonstrations.  These  demonstrations  stressed  the  portability  of  the 
integrated  system,  to  include  the  time  to  set-up  the  system  in  the  field. 

B.  SCOPE 

The  scope  of  this  research  was  limited  to  the  integration  and  testing  of 
components  previously  researched  by  Stephens  and  Adams  (2016)  and  selected  to  meet 
Commander,  Naval  Air  Forces  Atlantic  (CNAL)  capability  requirements.  This  research 
sought  to  integrate  the  chosen  solution  and  validate  Stephens  and  Adams’  selection.  As 
the  mobile  server  was  previously  evaluated  extensively,  the  primary  thrust  of  this 
research  was  to  assess  the  performance  of  the  satellite  terminal  and  demonstrate  the 
chosen  integrated  solution. 

C.  RESEARCH  QUESTIONS 

The  following  research  questions  were  formulated  based  on  the  requirements 
documents  provided  by  the  Office  of  Naval  Research  (ONR)  TechSolutions  office. 

Primary  question: 

•  How  can  the  video  processing  system  and  satellite  terminal  be  integrated? 

Secondary  questions  to  answer  once  the  described  components  are  integrated: 

•  How  can  the  integrated  system  provide  at  least  200Mbps  uplink  and 
downlink  speeds? 


1 


•  How  can  the  integrated  system  provide  less  than  30-millisecond  (120- 
millisecond  round-trip)  satellite  link  propagation  delays? 

•  How  can  the  system  support  the  delivery  of  real-time  video? 

D.  METHODOLOGY 

This  research  builds  upon  the  previous  research  (Stephens  &  Adams,  2016), 
integrating  the  NPS  video  cloud  server  with  an  03b  Medium  Earth  Orbit  satellite 
terminal.  Data  were  collected  and  analyzed  using  industry-standard  processing  and 
network  performance  measurement  tools. 

The  research  consisted  of  a  mix  of  lab  and  field  work.  Software  configuration  and 
testing  were  conducted  within  the  lab.  Live  operation  of  the  integrated  solution, 
consisting  of  the  satellite  terminal,  server,  and  camera,  was  performed  outdoors  at  the 
NPS  campus  and  at  Camp  Roberts,  CA. 

E.  BENEFITS  OF  STUDY 

The  primary  benefit  of  this  study  was  to  provide  a  required  capability  to 
Commander  Naval  Air  Forces  Atlantic  (CNAL)  Public  Affairs  Office  (PAO).  The 
required  capability  was  to  stream  live  4K  video  from  remote  locations  with  limited 
networking  infrastructure.  Additionally,  this  study  provided  data  on  the  use  of  emerging 
Medium  Earth  Orbit  satellite  systems  in  tactically-deployed  use  cases. 

F.  THESIS  OUTLINE 

The  remainder  of  this  document  is  organized  in  the  following  manner.  Chapter  II 
provides  background  information  used  to  design  and  conduct  this  research.  This 
information  includes  discussions  on  digital  video.  Chapter  III  discusses  the  design  of  the 
research,  including  the  test  plan  and  which  data  were  collected  during  the  research. 
Chapter  IV  provides  summary  results  of  the  research  and  includes  an  analysis  of  the 
observed  results.  Chapter  V  provides  a  summary  of  the  research,  as  well  as  conclusions, 
recommendations,  and  suggested  future  research. 
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II.  BACKGROUND 


Ultra  high  definition  (UHD)  video  is  rapidly  becoming  the  standard  video 
resolution  class  in  commercial  video  applications.  As  the  name  implies,  4K  images  and 
video  offer  approximately  four  times  the  amount  of  data  as  standard  HD  resolution 
media;  a  vast  amount  of  visually  rendered  digital  information. 

Increased  Internet  bandwidth  capabilities  worldwide  enable  greater  data 
throughput  capability,  driving  consumer  desire  for  higher  resolution  video  streaming 
products  that  provide  clear,  high-quality  imagery  on  their  television  at  home.  Emerging 
high  speed  satellite  capabilities  can  enable  the  satisfaction  of  end  user  high  bandwidth 
data  requirements  where  other  infrastructure  is  limited  or  non-existent. 

A.  DEFINITION  OF  UFTRA  HIGH  DEFINITION  VIDEO 

Digital  images  are  displayed  as  a  grid  of  colored  dots  called  pixels.  When  viewed 
together,  the  pixels  represent  a  view  of  the  light  captured  by  a  camera’s  sensor.  Video  is 
essentially  still  pictures,  referred  to  as  frames,  shown  one  after  the  other  to  simulate  live 
motion.  Changes  from  one  picture  to  the  next  give  the  illusion  of  movement.  The  more 
frequent  the  pictures  are  changed  per  second,  the  more  life-like  the  video  appears. 

UHD  video  is  a  class  of  video  resolutions  that  is  simply  greater  than  High 
Definition  (HD)  video.  Within  UHD,  there  are  several  standardized  resolution  formats 
and  “the  terms  are  purposefully  vague  due  to  the  varying  international  broadcast 
standards,  proliferation  of  camera  types  and  display  options”  (Stephens  &  Adams,  2016, 
p.  15).  For  the  purposes  of  this  research,  UHD  4K  was  utilized  at  a  resolution  of  3,840 
pixels  in  width  by  2,160  pixels  in  height. 

B.  BANDWIDTH  REQUIREMENTS  FOR  4K  VIDEO 

Still  and  video  cameras  use  a  wide  array  of  formats  to  capture  and  store  pictures 
and  video.  These  formats  are  generally  described  as  raw  photos  or  raw  video.  Raw 
formats  are  as  numerous  as  the  camera  sensor  manufacturers  and  have  little  impact  on  the 
standard  outputs  from  the  cameras.  Modern  cameras  offer  a  wide  variety  of  standard 
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output  formats,  but  almost  universally  offer  JPEG  for  pictures  and  MP4  containers  for 
video  encoded  using  the  H.264  standard. 

One  of  the  more  basic  digital  picture  formats  that  can  be  used  to  generally 
describe  raw  video  bandwidth  requirements  is  the  Windows  bitmap  format.  For 
simplicity’s  sake,  header  and  various  other  data  within  the  bitmap  format  are  not 
considered  in  this  illustration.  Figure  1  illustrates  how  pixels  are  stored  as  binary  data. 


This  figure  shows  a  magnified  3-  by  3-pixel  graphic  representing  a  simplified  bitmap 
image  file.  Each  pixel  is  defined  by  24  bits  of  data,  resulting  in  a  file  that  is  216  bits,  or 
24  bytes,  in  size. 


Figure  1.  Illustrative  Bitmap  Image 


To  calculate  the  disk  space  required  for  this  illustrative  bitmap  image,  multiply 
the  height  by  the  width  (in  pixels)  by  the  color  depth  (in  bits).  The  space  required  to  store 
a  4K  resolution  picture  captured  in  24-bit  color  as  a  bitmap  can  be  calculated  as  follows: 

3840  x  2160  x  24  =  199,065,600  bits 
Converted  to  the  more  commonly  used  bytes: 

199,065,600  bits  /  8  =  24,883,200  bytes  or  24.9  megabytes  (MB) 

Digital  video  is  generally  captured  at  24  frames  per  second  (fps)  up  to  60  fps.  A 
theoretical  bitmap  video  at  24  fps  would  require  the  following  amount  of  disk  space  per 
second  of  video: 
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24,883,200  bytes  x  24  =  597,196,800  bytes  or  597  MB 

A  typical  90-minute  motion  picture  captured  in  such  a  format  would  require  3,223,800 
MB  or  3.2  terabytes  (TB)  of  storage.  This  is  a  rather  large  amount  of  data  and  explains 
the  creation  of  encoding  and  compression  technologies. 

C.  ENCODING  DISCUSSION 

Due  to  the  high  resource  requirements  of  raw  imagery,  encoding  technologies 
were  created  to  increase  storage  and  transmission  efficiency.  Encoding  exchanges  disk 
space  for  computing  time.  When  applied  to  network  transmission,  space  is  translated  to 
bandwidth. 

For  encoded  4K  resolution  video,  the  data  volume  ranges  from  4.2  Gb/s  for 
moderate  subsampling,  10-bit  color  depth  and  24  frames  per  second  to  over  9.6  Gb/s  for 
RIB  (no  subsampling),  12-bit  color  depth  and  30  frames  per  second  (Halak,  Krsek,  Ubik, 
Zejdl,  &  Nevrela,  2011).  For  comparison  to  the  previous  discussion  on  raw  imagery, 
these  speeds  convert  to  bytes  as  follows: 

4.2Gb  =  4,200,000,000  bits  /  8  =  52,500,000  bytes  or  525.0  MB 

9.6  Gb  =  9,600,000,000  bits  /  8  =  1,200,000,000  bytes  or  1.2  GB 

Data  volume  rates  are  not  only  dependent  on  the  method  of  encoding,  but  also  the 
amount  of  motion  captured  in  the  video.  Video  encoders  begin  with  an  initial  image, 
called  an  intra  frame  (I-frame)  (Sethi  &  Patel,  1995).  The  I-frame  is  a  complete  image 
that  will  be  the  basis  for  other  frame  types. 

The  encoder  then  calculates  the  next  frame,  called  a  predicted  frame  (P-frame) 
(Sethi  &  Patel,  1995).  As  seen  in  Figure  2,  the  data  that  is  not  predicted  to  change  is  not 
encoded  into  the  P-frame.  This  results  in  lower  data  requirements  for  the  P-frame.  The 
more  similar  the  two  frames  are,  the  less  space  each  P-frame  will  consume.  Similarly, 
interpolated  bidirectional  frames  (B-frames)  are  encoded  from  previous  frames,  but  also 
use  future  frames  to  make  predictions  (Sethi  &  Patel,  1995). 
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l-frame  P-frame  B-frame  l-frame 

A  sequence  of  intra-coded,  predicted  and  bi-predicted  frames  in  a  compressed  video 
sequence. 


Figure  2.  I,  P,  and  B-Frames.  Source:  Amonen  (2009). 

D.  NETWORK  LATENCY 

Assuming  an  end-to-end  connection  of  the  required  bandwidth  is  available  for 
transmission,  each  component  in  a  system  introduces  its  own  latency  to  the  process  of 
transferring  captured  video  from  the  source  to  a  distribution  server.  Each  component 
through  which  video  data  passes  through  processes  that  data,  either  as  a  handoff  or  a 
transformation  of  some  sort.  These  delays,  though  only  nano-,  micro-,  or  milliseconds 
each,  compile  and  can  contribute  to  a  diminishing  feeling  of  real  time. 

The  primary  factor  affecting  latency  in  satellite  systems  is  the  distance  between 
the  satellite  and  the  Earth.  The  greater  the  distance  a  satellite  orbits  from  the  Earth,  the 
longer  it  will  take  a  satellite  signal  to  travel  to  and  from  the  satellite.  It  is  for  this  reason 
that  satellite  communication  systems  employing  closer  orbiting  satellites  are  being 
sought. 

Streaming  video  relies  not  only  on  low  latency  in  a  network,  but  also  on  stable 
network  latency  to  provide  quality  video  that  is  free  of  pauses  for  buffer  reset.  The 
evidence  can  be  seen  in  commercial  streaming  video  solutions  where  “extensive 
buffering  at  the  streaming  client  and  conservative  rate  selection,  in  order  to  obtain  smooth 
video  rendering  with  acceptable  bandwidth  utilization”  (Shuai,  Gorius,  &  Herfet,  2014, 
p.  1)  has  been  implemented.  For  this  reason,  it  is  important  for  any  analysis  of  satellite 
network  quality  to  include  data  regarding  network  latency  variations,  referred  to  as  jitter. 
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E.  SATELLITE  COMMUNICATIONS 


Satellite  communications  (SATCOM)  use  directed  radio  signals  from  terrestrial 
sources  to  satellite  vehicles  that  orbit  the  Earth.  These  signals  are  relayed  by  the  satellite 
to  other  terrestrial  receivers.  The  primary  benefit  of  such  systems  is  the  ability  to  conduct 
reliable  and  high  speed  over-the-horizon  communications. 

Early  proliferation  of  satellite  communications  utilized  geosynchronous  Earth 
orbit  (GEO)  vehicles  that  maintained  their  position  over  a  fixed  point  on  the  Earth’s 
surface.  While  this  made  for  less  complicated  terrestrial  equipment  that  did  not  have  to 
track  a  moving  satellite,  it  required  the  satellite  to  orbit  at  a  great  distance  from  Earth, 
which  directly  affects  the  round-trip  travel  time  of  the  satellite  signal. 

Kepler’s  laws  of  planetary  motion,  as  well  as  Newton’s  law  of  gravitation,  explain 
how  satellites  maintain  their  orbits  around  the  Earth.  GEO  satellites  maintain  an  orbit 
speed  that  is  synchronized  with  the  Earth’s  rotation  by  maintaining  a  position  further 
away  from  the  Earth.  The  satellite’s  distance  (R  in  Figure  3)  from  Earth  is  adjusted  so 
that  the  resultant  velocity  (v)  matches  the  Earth’s  rotational  speed,  allowing  the  satellite 
to  maintain  its  relative  position  over  the  Earth.  A  GEO  satellite’s  constant  relative 
position  enables  the  use  of  single  satellite  antenna  configurations. 
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Figure  3.  Gravitational  and  Centrifugal  Forces  Acting  on  Satellites  Orbiting 

Earth.  Source:  Maini  &  Agrawal  (2014). 

MEO  satellites  are  relatively  closer  to  the  Earth  and  experience  higher 
gravitational  forces.  The  satellite  orbits  at  a  higher  velocity  (v)  to  generate  the  appropriate 
centrifugal  force  in  order  to  counteract  gravitational  forces.  This  velocity  is  greater  than 
the  Earth’s  rotational  speed,  resulting  in  the  rising  and  setting  of  the  satellite  when 
viewed  from  a  fixed  position  on  the  Earth. 

MEO  satellite  systems  can  implement  an  orbiting  constellation  of  multiple 
satellites  to  provide  constant  coverage.  03b  Networks’  MEO  constellation  consisted  of 
14  satellites,  12  in  routine  use  and  two  in  reserve.  These  satellite  vehicles  orbited  at  8,062 
kilometers,  which  resulted  in  a  700-kilometer  spot  beam  at  sea  level  (03b  Networks, 
n.d.-b).  This  constellation  was  of  particular  interest  as  this  was  the  system  selected  as  the 
communications  capability  for  OnPARS. 

MEO  satellite  terminals  with  one  antenna  must  break  connection  with  a  setting 
satellite  in  order  to  connect  to  the  rising  satellite.  This  procedure  requires  1-2  minutes 
where  no  connection  is  available.  A  dual-antenna  design  as  depicted  in  Figure  4 
overcomes  this  shortcoming. 


8 


03b  MEO  Satellite  Handover  Process 
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This  figure  was  adapted  from  03b  Networks  training  materials  (A.  Jones,  personal 
communication,  08  September  2016). 


Figure  4.  03b  MEO  Satellite  Handover  Process. 


F.  NETWORK  PERFORMANCE  MEASUREMENT 

Many  tools  exist  to  measure  network  performance.  Standard,  time-tested 
command-line  utilities  like  Ping,  IPTraf,  and  iPerf  can  be  used  to  assess  latency,  monitor 
traffic  at  a  network  interface,  as  well  as  place  a  simulated  load  on  the  connection. 

An  important  measure  of  network  quality  is  jitter.  Jitter  represents  the  variation  in 
packet  arrival  time.  Networking  equipment  and  protocols  are  designed  to  account  for 
jitter,  but  wide  variations  can  have  an  effect  on  streaming  applications.  While  lower 
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values  of  delay  are  desirable,  it  is  more  important  that  the  delay  remain  consistent  so  it 
may  be  accounted  for  by  the  receiving  end. 

G.  BACKGROUND  SUMMARY 

UHD  video  is  a  class  of  video  characterized  by  its  high  data  requirements. 
Handling  and  transport  of  UHD  video  requires  large  amounts  of  resources,  both  storage 
and  bandwidth.  Transporting  UHD  video  requires  quality  network  conditions 
characterized  by  high  bandwidth  and  stable,  low-latency  connections.  This  requirement 
applies  to  all  segments  of  the  network  connection  between  the  server  and  client. 

Emerging  commercial  satellite  communications  systems  are  providing  lower 
latency,  higher  bandwidth  capabilities  than  previously  available  to  consumers.  MEO 
satellite  systems  in  particular  offer  quality  network  conditions  over  the  satellite  segment 
that  are  required  to  enable  quality,  high  resolution  video  streaming. 
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III.  DESIGN 


In  simplest  terms,  the  mobile  server,  also  called  the  Mini-XMS  (extreme  Media 
Server),  is  a  typical  desktop  computer  and  the  satellite  terminal  acts  much  like  a  home 
Internet  router.  The  link  between  the  satellite  terminal  and  the  Internet  via  the  03b 
Networks  infrastructure  can  be  likened  to  cable  or  digital  subscriber  line  (DSL)  Internet 
access  service.  The  4K  video  source  can  be  thought  of  as  a  webcam. 


DVIDS 


Portable  Server 


Figure  5.  OnPARS  System  Diagram 


A.  REQUIREMENTS 

The  following  requirements  were  extracted  from  the  CNAL  PAO  Statement  of 
Requirements: 

•  Must  support  full-resolution  UHD/4K  video  and  multiple  compressed 
video  streams  at  20Mbps 

•  Must  operate  bi-directionally  in  the  range  of  200-400  Mbps  (200  Mbps 
minimum) 
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•  Must  be  less  than  30-millisecond  link  propagation  delay  (120- millisecond 
round-trip  propagation  delay) 

B.  SATELLITE  TERMINAL 

The  satellite  ground  terminal  was  purchased  from  SES  Government  Solutions 
through  GSA  Advantage.  It  was  assembled  from  commodity  networking  equipment  and 
antennas  manufactured  by  AvL  Technologies.  Together,  the  outdoor  antenna  assemblies 
and  indoor  networking  equipment  comprised  the  Tracking  Fly  Away  Antenna  System 
(TFAAS)  (Stephens  &  Adams,  2016).  The  TFAAS  was  configured  by  SES  Government 
Solutions  and  03b  Networks  to  function  with  the  03b  Networks  MEO  satellite 
constellation. 

1.  Outdoor  Equipment 

The  TFAAS  outdoor  equipment  consisted  of  two  .85m  AAQ-1  antenna 
assemblies  (Figure  6)  and  two  100-foot  inter-facility  link  (IFF)  cable  assemblies.  The 
.85m  antenna  was  rated  to  receive  at  up  to  300Mbps  and  transmit  at  up  to  100Mbps.  And 
while  “other  satellite  configurations  utilize  a  1.0  m  or  1.2  m  reflector  panel  for  increased 
performance”  (Stephens  &  Adams,  2016,  p.  54),  the  .85m  antenna  was  selected  during 
Stephens  &  Adams’  research  to  provide  the  optimal  balance  between  performance  and 
man-portability.  On  a  highly-tuned  .85m  system,  upload  speeds  of  130Mbps  are  possible 
(T.  Kavanaugh,  personal  communication,  10  August  2016). 

The  cable  assemblies  provided  power,  control,  and  communication  connections 
between  the  indoor  equipment  and  the  antenna  assemblies.  Each  cable  was  calibrated  to 
its  particular  antenna  and  was  labelled  appropriately.  While  the  cables  are  constructed 
identically,  it  was  recommended  that  each  cable  was  connected  to  its  respective  antenna 
to  prevent  performance  degradation  (T.  Kavanaugh,  personal  communication,  10  August 
2016). 
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OiiPARS  antennas  are  set  up  on  the  roof  of  Spanagel  Hall  at  Naval  Postgraduate  School 
in  Monterey,  CA,  on  08  August  2016. 


Figure  6.  TFAAS  Antennas 

2.  Indoor  Equipment 

The  TFAAS’  indoor  equipment  provided  everything  required  for  the  operation  of 
the  terminal,  as  well  as  network  connection  for  external  devices,  such  as  a  video  server  or 
wireless  router.  This  consisted  of  a  network  router,  patch  panel,  network  switch,  and 
antenna  controllers  and  receivers.  The  indoor  equipment  is  housed  in  two  transportable 
rack- mount  cases,  as  shown  in  Figure  7. 
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Figure  7.  Rear  View  of  TFAAS  Indoor  Equipment 


The  indoor  equipment  also  included  the  power  supply  for  the  entire  terminal  (both 
indoor  and  outdoor  equipment).  The  power  supply  was  intended  to  be  connected  to  a 
grounded  115-volt  AC,  30-amp  power  source.  Normal  operation  of  the  terminal  does  not 
typically  draw  more  than  15  amps  of  power  (T.  Kavanaugh,  personal  communication,  10 
August  2016).  The  30-amp  design  was  meant  to  provide  enough  extra  capacity  for  windy 
conditions  that  require  extra  work  by  the  antenna  motors  to  keep  the  antennas  stabilized. 


14 


Wind  conditions  during  the  assessments  at  Camp  Roberts  were  light  enough  that  the 
terminal  was  able  to  run  on  standard  15/20A  wall  outlet  using  an  adapter  (Figure  8). 


Figure  8.  30-amp  to  15-amp  Adapter 


OnPARS  objectives  included  operation  of  the  system  in  a  forward-deployed 
location,  which  might  include  using  a  generator  as  a  power  source.  The  power  supply 
installed  in  OnPARS’  TFAAS  was  not  designed  to  operate  with  a  generator.  The  specific 
hazard  condition  that  could  have  arisen  was  a  ground  fault  loop.  This  condition  could 
have  caused  interference  with  the  signal  to  and  from  the  satellites,  significantly  degrading 
the  performance  of  the  system  (T.  Kavanaugh,  personal  communication,  10  August 
2016).  To  allow  OnPARS  to  be  powered  by  a  generator,  a  power  supply  specifically 
designed  to  accept  power  from  a  generator  can  also  be  installed  (T.  Kavanaugh,  personal 
communication,  2016). 
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c. 


VIDEO  SERVERS 


1.  Hardware 

The  Mini-XMS  consisted  of  typical  personal  computer  hardware,  including  a 
fourth-generation  Intel  i7  quad-core  processor,  16GB  of  random  access  memory  (RAM), 
and  multiple  solid-state  disk  (SSD)  drives  for  storage.  The  hardware  was  installed  in  a 
four-unit  (4U)  rack-mount  case  with  drawer  slides  to  facilitate  maintenance.  The  case 
was  then  installed  in  a  4U  travel  case  for  protection  during  transit,  which  also  included 
handles  to  facilitate  movement  by  hand. 

An  atypical,  but  still  COTS,  piece  of  hardware  installed  in  the  mobile  server  was 
the  DeckLink  Black  Magic  4K  Extreme  12G  video  capture  card.  This  component  enabled 
the  system  to  ingest  audio  and  video  from  a  multitude  of  source  devices,  including  the 
Panasonic  DMC-GH4  digital  camera  that  was  connected  via  its  high-definition 
multimedia  interface  (HDMI). 

2.  CentOS  6 

CentOS,  pronounced  “cent-oss”  (Hughesjr,  2005),  stands  for  Community 
Enterprise  Operating  System.  CentOS  is  a  Linux  kernel-based  operating  system  that  is 
derived  from  Red  Hat  Enterprise  Linux  (RHEL)  with  the  aim  of  being  functionally 
compatible  with  RHEL  (About  CentOS,  n.d.). 

The  Defense  Information  Systems  Agency  (DISA)  Security  Technical 
Implementation  Guide  (STIG)  for  Red  Hat  6  was  applied  to  both  the  mobile  and 

stationary  servers.  This  was  done  to  test  a  real-world  representative  solution  that  meets 

DOD  information  security  requirements.  Both  servers  were  also  updated  to  the  latest  6 
series  release  available  at  the  time  of  assessment,  CentOS  version  6.8. 

3.  viaPlatz  2.0 

viaPlatz  is  a  product  of  the  NTT  IT  Corporation  and  version  2.0  was  installed  on 
both  the  mobile  and  stationary  servers.  The  software  was  designed  to  ingest  video  and 
provide  content  delivery  and  collaboration.  viaPlatz’  more  granular  capabilities  included 
user  management,  video  transcoding,  and  media  management. 
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Discussions  with  NTT  IT  corporation  revealed  that  Teaming  Mode  functions,  as 
described  below,  were  not  available  in  Internet-connected  deployments  of  viaPlatz  2.0 
(Y.  Kato,  personal  communication,  13  June  2016).  For  viaPlatz  to  perform  the  desired 
functions  of  ingesting  video  remotely  and  transmitting  to  a  dedicated  server,  an  upgrade 
to  viaPlatz  3.0  was  required  (Y.  Kato,  personal  communication,  13  June  2016).  The 
viaPlatz  upgrade  would  have  also  required  an  operating  system  upgrade  to  CentOS  7  (Y. 
Kato,  personal  communication,  13  June  2016).  Funding  was  not  available  to  secure  the 
support  required  for  such  an  upgrade,  but  was  requested  for  eventual  execution. 

4.  FFmpeg 

Since  the  current  installation  of  viaPlatz  was  not  suitable  for  the  application, 
FFmpeg  was  selected  to  test  the  integrated  solution’s  ability  to  stream  4K  video.  FFmpeg 
is  a  complete,  open  source,  cross-platform  solution  to  record,  convert,  and  stream  audio 
and  video  (“About  FFmpeg”,  n.d.).  Pre-built  binaries  are  available  for  most  popular 
Linux  distributions,  including  CentOS. 

The  most  significant  drawback  to  using  FFmpeg  instead  of  viaPlatz  was  the  loss 
of  the  graphical  user  interface  (GUI).  viaPlatz’  GUI  enabled  the  automation  of  many 
transcoding  and  media  management  tasks  involved  in  an  efficient  video  production 
workflow.  While  those  functions  are  desirable  for  routine  use  by  public  affairs  personnel, 
FFmpeg  provided  the  necessary  functionality  to  assess  OnPARS’  video  streaming 
capabilities. 

The  BlackMagic  DeckLink  4K  Extreme  12G  video  capture  card  installed  in  the 
Mini-XMS  was  not  supported  by  FFmpeg  out-of-the-box  (OOB).  Due  to  this  lack  of 
OOB  support,  a  custom  build  of  FFmpeg  was  required  to  enable  the  BlackMagic 
DeckLink  video  capture  card.  The  source  code  for  FFmpeg  was  freely  available  for 
download  from  multiple  sources,  including  FFmpeg  Git  repositories  and  as  compressed 
archives  directly  from  its  website. 

FFmpeg  provides  a  compilation  guide  on  its  website  for  customization  of  their 
software  (“Compile  FFmpeg  on  CentOS”,  n.d.).  The  required  options  used  for  this 
particular  build  are  illustrated  in  Figure  9.  Key  build  options  that  were  required  for  this 
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application  were  libx264,  fdk_aac,  and  decklink.  The  libx264  and  fdk_aac  options  were 
required  to  enable  Flash  video  streaming  via  the  real-time  messaging  protocol  (RTMP)  to 
the  XMS  at  NPS.  The  decklink  option  was  required  to  enable  the  use  of  the  Mini-XMS’ 
video  capture  card  (“FFmpeg  devices  documentation”,  n.d.). 


•  ••  -t  Josh  — -bash  — 96x24 


Joshs-MBP:~  Josh$  PKG_CONFIG_PATH="$HOME/ffmpeg_buitd/lib/pkgconfig”  ./configure  --prefix="$HOME 
/ffmpeg.build”  - -ext ra-cf lags-" -I$HOME/ffmpeg_build/include"  --extra-ldflags-"-L$HOME/ffmpeg_bui 
td/tib”  --bindir="$HOME/bin"  --pkg-config-ftags="--static"  --enable-gpl  --enoble-nonfree  --enabt 
e-tibfdk-aac  --enable-libf reetype  --enable-libmp31ame  — enable-tibopus  — enable-libvorbis  — enab 
le-libvpx  --enable-libx264  --enable-libx265  --enable-decklink 


Figure  9.  FFmpeg  Build  Options 


To  enable  support  for  the  video  capture  card  in  FFmpeg,  BlackMagic’s  DeckLink 
Software  Development  Kit  (SDK)  was  required.  This  software  was  freely  available  for 
download  on  BlackMagic’s  website.  The  SDK  files  were  extracted  to  the  FFmpeg  build 
directories  as  described  in  FFmpeg’ s  compilation  guide  prior  to  FFmpeg  compilation. 

5.  Panasonic  Lumix  DMC-GH4  Digital  Camera 

A  Panasonic  Lumix  DMC-GH4  digital  single-lens  reflex  (DSLR)  camera  was 
used  previously  to  create  4K  and  HD  video  files  (Stephens  &  Adams,  2016)  to  assess  the 
transcoding  capabilities  of  the  Mini-XMS.  In  addition  to  4K  capture  capability,  the 
DMC-GH4  included  an  HDMI  output  that  could  be  used  to  connect  it  to  the  Mini-XMS’ 
video  capture  card.  For  this  reason,  the  same  model  camera  was  chosen  to  stream  live 
video  during  OnPARS’  assessment  at  Camp  Roberts,  CA  and  demonstration  in  Virginia. 

D.  USE  CASES 

There  are  multiple  ways  to  employ  the  equipment  included  in  OnPARS.  As  with 
any  IT  system,  how  the  components  are  connected  and  configured  can  greatly  vary  the 
capabilities  of  the  system.  This  research  explored  just  a  few  of  the  ways  that  OnPARS 
might  meet  the  research  objectives. 

The  particular  use  case  utilized  in  assessing  OnPARS  was  teaming  mode  using 
FFmpeg.  Teaming  mode  refers  to  more  than  one  server  working  in  concert  to  provide  a 
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desired  outcome.  In  this  case,  the  mobile  server  ingested,  transcoded,  and  transmitted  4K 
video  to  the  stationary  server  at  NPS  where  it  was  available  for  redistribution. 

1.  Mobile  Server  Standalone  Mode  Using  viaPlatz 

viaPlatz  functioned  as  an  all-in-one  video  processing  and  distribution  solution.  It 
offered  capabilities  to  ingest,  transcode,  edit,  collaborate  with  external  entities,  and 
deliver  high  quality  video  to  end  users.  viaPlatz  also  offered  user  management  functions, 
including  user  role  and  permission  functions.  In  a  standalone  configuration,  users  could 
login  directly  to  the  mobile  server  via  its  IP  address  or  an  assigned  fully  qualified  domain 
name  (FQDN). 

Use  of  the  mobile  server  in  standalone  mode  using  viaPlatz  over  a  satellite- 
enabled  Internet  connection  was  not  in  alignment  with  research  objectives.  Use  of 
standalone  mode  would  have  involved  clients  making  requests  to  the  mobile  server  over 
the  satellite  link.  While  the  Mini-XMS  is  frequently  referred  to  as  a  server,  it  should  be 
seen  more  as  a  data  source.  In  a  strict  client-server  model,  the  Mini-XMS  would  be  a 
client  to  the  XMS,  which  would  then  serve  video  to  other  clients. 

2.  Teaming  Mode  Using  viaPlatz 

viaPlatz  documentation  provided  evidence  of  multiple  servers  working  together  in 
a  myriad  of  use  cases  under  a  local  area  network  (LAN)  environment.  Any  single 
viaPlatz  server  could  be  configured  as  the  “master”  server,  controlling  the  work  of  the 
other  servers  (Figure  10).  Teaming  functionality  was  not  available  for  Internet-connected 
applications  with  viaPlatz  2.0. 
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viaPlatz 


Copy/Transcode 


Transfer 


Export 

This  figure  illustrates  how  workload  functions  can  be  delegated  between  multiple 

machines  with  viaPlatz  software  installations. 

Figure  10.  Plural  XMS  Deployment.  Source:  NTT  IT  Corporation  (2015). 

It  may  have  been  possible  to  use  a  virtual  private  network  (VPN)  to  simulate  a 
LAN  environment,  thus  enabling  viaPlatz  teaming  mode.  Use  of  the  NPS  VPN  to  assess 
this  capability  was  considered,  but  the  network  performance  would  not  have  met  research 
objectives.  According  to  Stephens  and  Adams’  study  (2016),  the  network  speed  while 
utilizing  the  NPS  VPN  was  limited  to  38.87  Mbps  upload  and  11.72  Mbps.  The  same 
study  also  found  that  network  latency  in  excess  of  200ms  was  present  during  NPS  VPN 
use  was  also  excessive. 

3.  Mobile  Server  Standalone  Mode  Using  FFmpeg 

While  FFmpeg  lacked  the  collaboration  and  user  management  functions  of 
viaPlatz,  it  was  capable  of  serving  as  a  video  capture  and  streaming  application.  FFmpeg 
was  used  to  capture  video  directly  from  the  4K  video  source,  using  the  installed  video 
capture  card.  FFmpeg  also  performed  the  encoding  functions  as  input  by  the  user. 
FFmpeg’ s  output  could  be  saved  as  a  file  or  directed  to  a  network  location  via  the  mobile 
server’s  network  connection. 


20 


4.  Teaming  Mode  Using  FFmpeg 

To  use  OnPARS  in  teaming  mode  with  FFmpeg,  web  server  software  was 
installed  on  the  stationary  server  as  a  substitute  for  viaPlatz.  Customized  NGINX 
(pronounced  “engine  x”)  web  server  software  was  installed  on  the  XMS  with  support  for 
RTMP  streaming.  This  allowed  the  XMS  to  retransmit  the  live  video  stream  sent  from  the 
Mini-XMS.  This  configuration  reduced  the  load  on  the  satellite  link  by  requiring  only  a 
single  transmission  of  the  streaming  video  to  the  XMS.  Distribution  of  the  video  was  then 
handled  by  the  XMS  over  terrestrial  links. 


#  •  #  'f'  Josh - bash  —  96x24 


Joshs-MBP:~  Josh$  ffmpeg  -f  decktink  -i  'DeckLink  4K  Extreme@20'  -vi.deo_i.nput  hdmi  -bm_v210  1  -c 
:a  libfdk_aac  -b:a  128k  -vcodec  libx264  -preset  veryfast  -tune  zerotatency  -f  flv  -flv_metadata 
true  rtmp : //xms . nps . edu/ti ve/test 


Figure  11.  FFmpeg  Stream  Initiation  Command 

5.  Live  Streaming  to  DVIDS  using  FFmpeg 

DVIDS  used  the  Akamai  content  delivery  network  (CDN)  to  receive  and  manage 
streaming  video.  Streaming  from  the  mobile  server  required  directing  the  stream  to  a 
uniform  resource  locator  (URL)  provided  by  DVIDS.  Other  than  changing  the  output 
URL,  live  streaming  to  DVIDS  was  essentially  the  same  as  teaming  mode  using  FFmpeg. 

E.  TEST  PLAN 

A  test  plan  was  developed  to  guide  the  research  team  during  assessment  of 
OnPARS.  It  was  based  on  the  background  information  discussed  in  Chapter  II  as  well  as 
the  experiment  design  criteria  discussed  earlier  in  this  chapter.  The  test  plan  was  used  to 
ensure  relevant  data  was  collected  and  that  the  assessments  were  conducted  in  methodical 
way  in  support  of  answering  the  research  questions. 

1.  System  Description 

OnPARS  resulted  from  research  efforts  at  the  Naval  Postgraduate  School  (NPS) 
implementing  cloud  video  processing  and  storage  systems  and  transmission  of  Internet 
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Protocol  (IP)  transmitted  over  emerging  high  speed  satellite  systems.  This  research 
integrated  two  major  subcomponents  into  the  OnPARS  system: 


•  A  dual-server  subsystem  that  utilizes  video  processing  and  collaboration 
software  from  NTT  IT  Electronics.  One  server  is  installed  in  a  portable 
enclosure  and  can  be  equipped  with  a  DC  power  source  for  use  in  remote 
locations.  The  second  server  is  housed  in  a  data  center  and  collects 
transmitted  imagery  from  the  portable  server. 

•  A  .85m  dual-antenna  satellite  terminal  purchased  from  SES  Government 
Solutions  designed  to  work  with  the  03b  Medium  Earth  Orbit  (MEO) 
satellite  constellation. 

2.  Objective 

The  objective  of  the  tests  is  to  determine  the  suitability  of  the  offered  solution  to  a 
capability  gap  identified  by  the  Commander  Naval  Air  Forces,  U.S.  Atlantic  Fleet 
(COMNAVAIRLANT  or  CNAL).  The  requirements  to  close  the  identified  gap  were: 


•  Transmission  of  an  ultra  high  definition  video  stream  (also  referred  to  as 
4KHD). 

•  Capability  to  transmit  multiple  high  definition  video  streams. 

•  Bidirectional  data  transmission  rates  up  to  400Mbps. 

•  Less  than  30-millisecond  satellite  link  propagation  delay. 

•  Less  than  120-millisecond  round-trip  propagation  delay. 

•  Support  reach-back  from  remote  locations,  such  as  disaster  or 

humanitarian  operations  areas. 

3.  Validation 

To  validate  OnPARS,  the  following  assessments  were  conducted: 


•  Connection  testing  from  the  portable  server  to  the  stationary  server, 
including  round-trip  delay  measurements; 

•  Live  stream  of  encoded  4K  video  to  the  stationary  server  at  NPS; 

•  Live  stream  of  encoded  4K  video  to  DVIDS. 
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During  the  connection  tests,  bandwidth,  latency,  and  jitter  were  measured  using 
several  common  network  troubleshooting  and  measurement  tools.  The  network 
troubleshooting  tool,  Ping,  was  used  to  measure  packet  loss  and  round-trip  delay 
(latency).  Another  network  measurement  tool,  iPerf  (both  versions  2  and  3),  was  used  to 
place  a  dummy  load  on  the  network  connection  from  the  mobile  server  to  the  stationary 
server.  iPerf  has  both  a  TCP  and  UDP  mode  and  both  were  used  to  inject  required  data 
types. 


4.  Data  Collection  Plan 

Each  network  measurement  tool  could  have  its  output  saved  as  standard  Unix  text 
files.  This  was  done  and  the  files  were  parsed,  allowing  the  data  to  be  extracted  and 
transferred  to  spreadsheet  programs  for  analysis.  The  tools  provided  some  overlapping 
data  types,  as  well  as  their  own  unique  data. 

Output  from  Ping: 

•  Percentage  of  packet  loss. 

•  Minimum,  average,  maximum,  and  standard  deviation  of  latency. 

Output  from  iPerf: 

•  Amount  of  data  transferred. 

•  Speed  at  which  the  data  was  transferred  (throughput). 

•  Average  variation  in  delay  of  data  transfer  (jitter). 

Output  from  IPTraf: 

•  Average  and  peak  outgoing  data. 

•  Average  and  peak  incoming  data. 

•  Average  and  peak  total  data. 

Output  from  FFProbe: 

•  Coded  picture  number; 

•  Picture  type; 

•  Packet  size. 
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Subjective  analysis  on  the  quality  of  the  live  video  was  also  conducted.  This 
analysis  corroborated  the  quantified  data,  ultimately  answering  the  question  of  whether 
the  system  was  “usable”  for  live  4K  video  transmission. 

5.  Schedule 

Satellite  airtime  was  the  major  driver  of  the  testing  schedule.  Airtime  was 
coordinated  for  the  West  Coast  of  the  United  States  from  8  August  2016  to  12  August 
2016.  For  U.S.  East  Coast  testing  and  demonstration,  airtime  was  coordinated  for  30 
August  2016  through  31  August  2016,  but  was  later  rescheduled  to  8  September  2016 
through  9  September  2016.  Testing  of  the  integrated  solution  commenced  in  July  2016 
and  all  testing  was  complete  in  September  2016. 

Three  test  events  were  scheduled: 

•  Initial  integration  of  the  video  servers  and  TFAAS  were  conducted  at  the 
NPS  campus. 

•  OnPARS  was  transported  to  Camp  Roberts,  CA  for  a  performance 
assessment  during  the  NPS-sponsored  Joint  Interagency  Field  Exercise 
(JIFX)  from  10  August  2016  to  12  August  2016. 

•  The  final  assessment  was  conducted  in  Reston,  VA  as  a  demonstration  to 
the  research  sponsor,  the  Office  of  Naval  Research  (ONR)  Technology 
Solutions  on  08  and  09  September  2016. 

6.  Personnel 

Testing  was  conducted  by  the  Naval  Postgraduate  School  Research  Working 
Group  (NRWG)  with  support  from  03b  Networks  and  SES  Government  Solutions 
personnel.  The  NPS  research  team  consisted  of: 

•  primary  investigator,  John  H.  Gibson; 

•  research  and  thesis  advisor,  Dr.  Douglas  J.  MacKinnon; 

•  graduate  student  from  the  NPS  Graduate  School  of  Information  Sciences 
(GSOIS),  LT  Joshua  A.  Clements,  United  States  Navy  Reserve  (USNR). 
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F.  DESIGN  SUMMARY 

This  research  utilized  a  COTS  satellite  terminal  and  commodity  computing 
equipment  to  stream  4K  video  from  a  remote  location  over  a  commercial  MEO  satellite 
constellation.  The  satellite  terminal  utilized  for  this  research  was  the  Tracking  Fly  Away 
Antenna  System  (TFAAS)  and  was  available  through  GSA  Advantage.  The  TFAAS  used 
for  this  research  was  configured  to  connect  to  03b  Networks’  MEO  satellite 
constellation.  Readily  available  computing  equipment  was  utilized  to  ingest,  encode,  and 
transmit  4K  video  that  was  captured  from  a  common  DSFR  camera.  The  available  media 
management  software,  viaPlatz  2.0,  that  was  previously  identified  did  not  have  the 
capabilities  required  for  this  research.  Alternate  software  solutions,  FFmpeg  and  NGINX, 
were  selected  and  utilized  to  assess  the  system’s  ability  to  stream  4K. 

The  subsystems  were  integrated  at  NPS  and  assessed  in  a  field-representative 
environment  at  Camp  Roberts,  CA.  Following  the  assessments,  OnPARS  was  transported 
to  Manassas,  VA  where  it  was  demonstrated  to  ONR  TechSolutions  personnel.  Chapter 
IV  provides  the  results  and  analysis  of  the  data  collected  during  those  assessments. 
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IV.  RESULTS  AND  ANALYSIS 


The  assessment  results  provided  in  this  chapter  represent  a  snapshot  of  the 
configuration  of  OnPARS  at  the  time  of  assessment.  Data  were  collected  on  11  August 
2016  at  Camp  Roberts,  CA,  with  the  exception  of  some  iPerf3  and  Ping  data  that  were 
automatically  collected  through  the  night  until  the  morning  of  12  August  2016.  The  data 
were  collected  from  the  respective  tool  as  redirected  standard  output  to  text  file.  After 
collection,  the  data  were  parsed  into  comma- separated  value  files  for  processing  using 
Microsoft  Excel.  Figures  13  through  21  are  derived  from  the  data  tables  provided  in 
Appendix  B. 

A.  RESULTS 

iPerf3  utilized  a  client-server  model  where  one  node  sent  data  and  a  second  node 
received  data.  The  iPerf3  commands  determine  which  node  acts  as  the  sender  and  which 
as  the  receiver  during  the  specific  session.  Both  the  iPerf3  sender  and  the  iPerf3  receiver 
reported  data,  providing  two  data  points  for  each  iPerf3  session. 

All  commands  were  issued  from  the  Mini-XMS,  but  alternating  commands  were 
issued  to  capture  data  where  the  Mini-XMS  and  the  XMS  each  alternated  roles  as  the 
iPerf3  sender  and  receiver.  Figure  12  displays  the  script  used  by  the  Mini-XMS  to  initiate 
iPerf  and  Ping  sessions.  The  commands  within  the  script  also  redirected  the  output  from 
those  tools  to  text  files. 

iPerf  and  iPerf3  sessions  were  configured  to  run  for  a  certain  period  of  time.  iPerf 
sessions  were  configured  to  last  for  30  seconds.  iPerf3  had  the  capability  to  push 
information  over  the  link  for  a  specified  amount  of  time  without  collecting  the  data, 
essentially  allowing  the  session  to  “warm-up”.  This  was  done  to  remove  some  of  the 
fluctuations  that  can  occur  early  in  a  connection  when  TCP  parameter  negotiations  are 
occurring,  commonly  referred  to  as  TCP  slow  start.  iPerf3  sessions  were  configured  to 
use  a  10-second  “warm-up”  followed  by  40  seconds  of  data  capture. 
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#  #  9  networkTests.sh 

#!  /bin/bash 

/bin/ping  -c  10  8. 8. 8. 8  >  \ 

/home/ jclements/Documents/testResults/ping/mobileServer-GoogleDNS_$( date  +%Y%m%d_%H%M ) 
/usr/local/bin/iperf3  -c  205.155.65.150  -p  443  -0  10  -t  40  >  \ 

/home/ jclements/Documents/testResults/iperf3/mobileServer-NPS_$( date  +%Y%m%d_%H%M ) 

/usr/local/bin/iperf3  -c  205.155.65.150  -p  443  -0  10  -t  40  -R  >  \ 

/home/ jclements/Documents/testResults/iperf3/NPS-mobileServer_$( date  +%Y%m%d_%H%M ) 

/usr/local/bin/iperf  -c  162.249.178.54  -t  30  -b  100M  >  \ 

/home/ jclements/Documents/testResults/iperf/tcp_mobileServer_o3bHubVernon_$( date  +%Y%m%d_%H%M ) 
/usr/local/bin/iperf  -c  162.249.178.54  -t  30  -b  100H  -u  -p  5000  >  \ 

/home/ jclements/Documents/testResults/iperf/udp_mobileServer_o3bHubVernon_$( date  +%Y%m%d_%H%M ) 


Figure  12.  Network  Tool  Initiation  Commands 

The  Mini-XMS  was  configured  to  automatically  initiate  an  iPerf3  session  every 
10  minutes.  The  automated  script  was  repeatedly  executed  for  almost  18  hours  in 
duration.  Figures  13  through  15  show  the  collected  average  bandwidth  measurement  data 
in  graphical  form.  The  figures  also  depict  the  differences  between  what  was  reported  by 
the  iPerf3  sender  and  by  the  iPerf3  receiver.  The  total  data  presented  in  Figure  15 
represents  data  from  iPerf3  sessions  in  which  the  Mini-XMS  is  the  sender.  The 
summarized  data  shown  in  Figure  15  indicates  that  the  Mini-XMS  was  able  to  transmit  at 
an  average  of  67.3Mbps  and  a  median  of  70.4Mbps. 
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Figure  13.  iPerf3  Results  -  Mobile  Server  at  Camp  Roberts  to  Stationary  Server 

at  NPS 
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Figure  14.  iPerf3  Results  -  Stationary  Server  at  NPS  to  Mobile  Server  at  Camp 

Roberts 
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iperf3_mobile-to-NPS 


Figure  15.  iPerf3  Summarized  Bandwidth  Measurements  from  Mobile  Server  to 

Stationary  Server  at  NPS 

Ping  was  used  to  measure  packet  delay  time.  The  Mini-XMS  was  configured  to 
automatically  send  10  ping  requests  every  10  minutes.  Each  data  point  represents  the 
average  round-trip  time  as  calculated  by  Ping.  The  NPS  network  was  configured  to  block 
Ping  requests  to  the  XMS,  so  a  public  DNS  server  owned  by  Google  was  used  to  gather 
the  data  depicted  in  Figure  16.  The  figure  includes  a  mean  line  generated  by  Microsoft 
Excel  based  on  the  data  provided  in  Appendix  B,  Table  3.  The  derived  line  shows  that  the 
mean  latency  was  just  over  158ms,  with  point  measurements  as  high  as  161ms  and  as  low 
as  156ms. 
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Figure  16.  Ping  Results 


In  an  effort  to  capture  data  that  represented  the  satellite  link  network  performance, 
iPerf  version  2  was  used  to  connect  to  an  iPerf  version  2  server  at  03b  Networks’  point 
of  presence  (PoP)  in  Vernon,  TX.  This  server  at  the  PoP  was  operated  and  maintained  by 
03b  Networks  and  was  only  available  for  approximately  four  hours.  It  would  have  been 
optimal  to  use  iPerf3  for  a  better  comparison  to  data  collected  during  sessions  between 
the  XMS  and  Mini-XMS,  but  iPerf  (version  2)  was  the  only  option  available  on  03b 
Networks’  systems  at  the  PoP.  The  iPerf  UDP  tests  also  collected  data  on  datagram  loss. 
The  observed  datagram  loss  rate  was  a  constant  24-25%  (see  Table  5  in  Appendix  B). 
There  was  no  observed  reason  for  this  packet  loss  and  the  link  seemed  to  function 
normally. 
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Figure  17.  iPerf  TCP  Results 
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Figure  18.  iPerf  UDP  Results 
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Figure  19.  iPerf  TCP  and  UDP  Mode  Bandwidth  Comparison 


Figure  20.  iPerf  Jitter  Results 

In  addition  to  the  artificial  loading  of  the  network  connection  with  iPerf  and  Ping, 
IPTraf  was  used  to  capture  the  amount  of  data  actually  leaving  the  Mini-XMS  while 
streaming  live  video.  The  randomly  collected  data  are  depicted  in  Figure  21  and  were 
measured  in  kilobits  per  second  (kbps).  The  data  showed  a  peak  transmission  rate  of 
3,400kbps,  or  3.4Mbps,  with  average  transmission  rates  below  1,400kbps,  or  1.4Mbps. 
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Figure  2 1 .  IPTraf  Results 

FFProbe  was  a  component  of  FFmpeg  used  to  evaluate  the  quality  of  captured 
media  files.  DVIDS  captured  data  on  the  stream  transmitted  from  OnPARS  using 
FFProbe.  Figure  22  is  a  graphical  depiction  of  the  FFProbe  output  DVIDS  provided.  The 
spikes  represent  I-frames  and  the  rest  of  the  data  (below  the  28,000  bytes  line)  represent 
P- frames.  No  B -frames  were  captured. 
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Figure  22.  FFProbe  Results 


34 


B.  ANALYSIS 


Multiple  video  streams  were  not  assessed,  but  the  bandwidth  measurements 
suggest  that  at  least  three  20Mbps  streams  could  be  supported  by  the  satellite  link.  The 
peak  amount  of  data  observed  leaving  the  Mini-XMS’  network  interface  was 
approximately  3.4Mbps,  as  shown  in  Figure  21.  These  data  suggest  that  TFAAS  could 
support  19  or  more  similar  streams,  based  on  the  average  bandwidth  measurement  of 
67.3Mbps,  as  shown  in  Figure  15.  However,  creating  more  streams  would  require 
additional  and/or  different  hardware,  such  as  dedicated  video  encoding  equipment. 

The  data  collected  did  not  suggest  that  the  TFAAS  equipped  with  .85m  antennas 
could  support  the  required  200Mbps  minimum  total  bandwidth.  However,  03b  Networks 
personnel  stated  that  the  terminal  could  transmit  at  up  to  130Mbps  in  an  optimized 
configuration  that  would  be  calibrated  for  its  exact  location  (T.  Kavanaugh,  personal 
communication,  10  August  2016).  If  calibration  and  optimization  of  the  terminal  resulted 
in  the  100Mbps  transmission  rates  for  which  the  .85m  antennas  are  designed,  OnPARS 
could  meet  the  minimum  requirement  of  200Mbps  total  bandwidth. 

The  collected  Ping  data  suggests  that  OnPARS  will  likely  not  meet  the 
requirement  for  a  maximum  round-trip  latency  of  120ms.  03b  Networks  advertised 
performance  was  130ms  for  just  its  MEO  satellite  system.  The  public  Internet  that  was 
used  during  OnPARS’  assessment  comes  with  its  own  varied  and  uncontrollable  latency 
conditions.  Latency  is  also  introduced  by  the  Mini-XMS  and  its  connection  to  TFAAS. 
Despite  these  conditions,  OnPARS  experienced  an  average  of  158ms  of  packet  delay  and 
very  little  jitter,  indicating  that  the  evaluated  configuration  of  OnPARS  performed  well 
for  the  desired  video  streaming  application. 

The  collected  jitter  data  suggest  that  the  TFAAS  provided  a  stable  connection 
over  03b  Networks’  MEO  satellite  constellation  that  is  suitable  for  streaming  video 
transmission.  However,  the  observed  24-26%  UDP  datagram  loss  rates  were  excessive. 
Murphy,  Searles,  Rambeau,  &  Murhpy  (2004)  observed  that  “loss  rates  in  excess  of  6%... 
resulted  in  very  poor  quality  video.”  OnPARS  video  transmission  was  assessed  using 
RTMP,  a  TCP-based  protocol  that  would  compensate  for  any  data  loss  by  retransmitting 
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dropped  packets.  If  the  data  loss  was  also  present  during  TCP-based  connections, 
OnPARS  would  ultimately  experience  degraded  performance  at  a  theoretical  rate  of  24- 
26%.  Further  research  into  the  cause  of  the  data  loss  and  correcting  it  could  yield 
increased  network  performance,  possibly  increasing  the  bandwidth  capacity  closer  to  the 
100Mbps  for  which  the  antennas  are  designed. 

The  iPerf3  data  is  interesting  because  it  reveals  a  difference  between  TCP 
sessions  that  are  sent  from  either  side  of  the  satellite  connection.  When  the  mobile  server 
acted  as  the  receiver  in  an  iPerf3  session,  the  captured  data  revealed  an  average  of 
approximately  12Mbps  less  bandwidth  available  (see  Appendix  B,  Tables  1  and  2).  This 
is  important  because  it  shows  a  significantly  lower  value  than  when  the  mobile  server 
acted  as  the  sender  during  the  iPerf3  session.  This  supports  the  suggested  architecture  of 
a  stationary  server  handling  the  distribution  of  the  processed  video  over  terrestrial  links 
as  TCP  sessions  initiated  to  the  mobile  server  across  the  satellite  link  may  experience 
degraded  performance. 

In  addition  to  the  quantitative  results,  the  research  team  was  able  to  view  the 
distributed  video  stream  from  both  the  XMS  and  from  DVIDS  as  a  client  on  the  Mini- 
XMS’  monitor.  The  tested  configuration  streamed  quality  video  that  arrived  back  to  the 
portable  server  in  8-20  seconds.  This  should  be  acceptable  for  a  media  release  scenario. 

C.  RESULTS  AND  ANALYSIS  SUMMARY 

The  captured  data  indicate  that  OnPARS  was  not  able  to  quantitatively  meet  all 
Commander  Naval  Air  Forces  Atlantic  (CNAL)  requirements  as  listed  in  Chapter  III. 
However,  OnPARS  was  able  to  perform  the  desired  functions  that  were  described  in  the 
Statement  of  Requirements  from  which  the  requirements  in  Chapter  III  were  derived. 
Ultimately,  OnPARS  was  able  to  transmit  UHD/4K  streaming  video  at  3840  by  2160 
resolution  over  03b  Networks  MEO  satellite  network  and  it  was  also  able  to  provide  a 
quality  4K  stream  to  DVIDS. 
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V.  SUMMARY  AND  CONCLUSIONS 


The  On-location  Public  Affairs  Reach-back  System  (OnPARS)  provided  a 
rudimentary  model  for  the  implementation  of  satellite-enabled  IP-based  information 
system  solutions  for  DOD.  The  high-bandwidth,  low-latency  connection  provided  over 
the  03b  Networks  Medium  Earth  Orbit  (MEO)  constellation  enabled  the  near  real-time 
streaming  of  ultra  high  definition  (UHD)  video  to  a  well-established  Defense  public 
media  outlet.  The  connection  is  useful  to  any  number  of  IP  applications  in  the  DOD. 

A.  RESEARCH  SUMMARY 

This  research  evaluated  an  integrated,  satellite-enabled,  portable  UHD  video 
processing  solution  constructed  from  commercial  off-the-shelf  (COTS)  components. 
These  components  included  a  typical  digital  camera  capable  of  UHD  resolution  captures, 
general  purpose  computing  equipment  for  ingestion  and  processing  of  video,  and  a 
Tracking  Fly  Away  Antenna  System  (TFAAS)  for  transmission  over  a  Medium  Earth 
Orbit  (MEO)  satellite  communications  system. 

Following  preliminary  integration  of  the  components  at  the  Naval  Postgraduate 
School  (NPS)  campus,  OnPARS  was  transported  to  Camp  Roberts,  CA,  for  assessment  in 
an  operationally  representative  environment.  OnPARS  was  able  to  provide  an  average  of 
67Mbps  of  bandwidth  and  experienced  an  average  of  158ms  of  latency  with  very  little 
jitter  (less  than  1ms).  These  network  connection  characteristics  suggested  that  OnPARS 
would  be  able  to  support  the  transmission  of  multiple  streams  of  high-quality  UHD  video. 

OnPARS’  ability  to  stream  UHD  video  was  also  assessed.  Live  4K  video  was 
streamed  from  the  mobile  server  at  Camp  Roberts  to  the  stationary  server  in  the  NPS  data 
center  where  it  could  be  accessed  by  requesting  clients.  The  mobile  server  at  Camp 
Roberts  was  able  to  access  and  view  its  own  stream  on  an  attached  monitor.  The  streamed 
video  was  viewable  on  the  monitor  approximately  8-20  seconds  after  it  was  ingested  by 
the  camera.  Additional  4K  streaming  was  performed  to  the  Defense  Video  Imagery 
Distribution  System  (DVIDS)  via  the  Akamai  content  delivery  network  (CDN)  with 
similar  round  trip  viewing  time. 
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OnPARS  was  then  transported  to  Manassas,  VA,  for  demonstration  to  Office  of 
Naval  Research  TechSolutions  personnel.  Moving  the  system  caused  the  satellite  signal 
to  be  routed  through  different  03b  Networks  gateways  and  Internet  points  of  presence 
(PoP).  Though  data  was  not  captured  during  the  demonstration,  OnPARS  displayed 
similar  performance  to  that  of  its  assessments  at  Camp  Roberts. 

B.  RECOMMENDATIONS 

NTT  IT  Corporation  suggested  that  the  desired  dual-server  teaming  configuration 
could  work  with  the  newer  version  of  their  software,  viaPlatz  3.0.  An  upgrade  to  viaPlatz 
3.0  also  required  an  operating  system  upgrade  to  CentOS  Version  7  or  above.  The 
performance  of  these  upgrades  is  recommended  to  further  enhance  OnPARS  capabilities. 

FFmpeg  is  a  versatile  open  source  product  that  has  been  integrated  into  many 
other  projects  but  it  lacks  intuitiveness  and  is  not  friendly  to  the  average  user.  A  more 
user-friendly  graphical  user  interface  (GUI)-based  solution  should  be  sought  to  provide  a 
reliable  and  easy  to  use  product  for  deployed  forces.  This  could  have  an  impact  on  the 
annual  maintenance  costs  for  the  servers.  Additionally,  Adobe  Media  Server  (AMS),  a 
standard  industry  media  server  solution,  was  an  integral  component  of  viaPlatz  2.0. 
Should  an  upgrade  to  viaPlatz  3.0  not  be  pursued,  alternative  solutions  using  AMS  could 
be  explored. 

Discussions  with  DVIDS  personnel  during  the  course  of  the  research  revealed  that 
DVIDS  had  a  model  for  deploying  a  mobile  media  team.  The  DVIDS  solution  also 
included  a  Linux-powered  mobile  video  system  that  was  configured  to  capture  and 
process  HD  video.  Further  refinement  of  OnPARS’  capabilities  and  requirements  should 
involve  consultation  with  DVIDS  mobile  video  team  management  personnel.  Not  only 
could  the  knowledge  provided  by  DVIDS  personnel  enable  a  more  efficient  workflow  for 
OnPARS  but  DVIDS  could  benefit  from  the  experience  with  higher  quality  video 
transmission  over  high  bandwidth  connections. 
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C.  FUTURE  RESEARCH 

This  research  studied  how  to  integrate  a  video  processing  solution  and  an  MEO 
satellite  terminal  to  deliver  UHD  video  from  remote  locations.  Opportunities  for  further 
investigation  emerged  during  the  course  of  this  research  and  are  presented  below. 

1.  Hardware  Encoding 

OnPARS  used  general  purpose  computing  equipment  to  encode  digital  video. 
During  the  research,  high  utilization  of  system  resources  was  noted.  Additionally,  the 
limitations  of  the  fourth-generation  quad-core  Intel  i7  precluded  the  use  of  some  of 
FFmpeg’s  higher  quality  presets.  These  limitations  may  cause  concern  over  the  future 
viability  of  the  computing  equipment  assessed  in  this  research. 

Use  of  specialized  hardware  encoders  would  be  especially  useful  in  implementing 
potential  successors  to  the  H.264/AVC  standard  that  was  used  during  this  research.  The 
High  Efficiency  Video  Coding  (HEVC)  standard,  also  called  x265  or  H.265,  is  one  such 
standard  that  has  displayed  significant  bitrate  savings  over  H.264.  “Compared  with  the 
H.264/AVC  standard,  the  computational  complexity  of  HEVC  encoding  is  extremely 
high,  making  it  hard  to  implement  a  real-time,  high-quality  software  HEVC  encoder  on 
general  purpose  processors  widely  used  in  cloud-based  multimedia  encoding/transcoding 
systems’’  (Chen,  Wen,  Wen,  Tang,  &  Tao,  2015,  p.  1423).  The  use  of  dedicated  video 
encoding  hardware  is  a  possible  solution  to  previously  mentioned  shortcomings,  in 
addition  to  further  optimizing  OnPARS’  capabilities. 

2.  Maritime  Satellite  Terminal 

Given  TFAAS’  COTS  nature,  various  components  were  available  that  could 
allow  for  a  wide  variety  of  capability  configurations.  One  such  configuration  allowed  for 
the  integration  of  the  terminal  into  a  maritime  platform.  Though  costlier  than  the  .85m 
land-based  antennas  used  in  OnPARS,  stabilized  maritime  antennas  were  available  to 
provide  service  to  ships  at  sea  via  03b  Networks’  MEO  satellite  system.  03b  Networks 
was  providing  MEO  satellite  connectivity  to  a  number  of  commercial  cruise  lines, 
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providing  a  model  suitable  for  research  into  the  implementation  of  MEO  systems  on 
Naval  vessels. 


3.  Large-scale  Deployment  of  MEO  SATCOM 

It  should  be  obvious  that  higher  bandwidth,  lower  latency  SATCOM  systems 
could  increase  the  operational  capabilities  of  forces  deployed  around  the  world.  What 
may  not  be  so  obvious  is  whether  MEO  satellite  systems  could  offer  an  increase  in 
operational  capability  that  would  warrant  the  investment  in  upgrading  the  existing  DOD 
SATCOM  infrastructure.  Perhaps  the  most  interesting  opportunity  is  the  possibility  of 
replacing  legacy  GEO  satellite  systems  with  higher  performing  systems  for  all  Services, 
thereby  offering  increased  SATCOM  capabilities  that  are  normalized  within  DOD. 
Several  areas  of  research  are  possible,  including,  but  not  limited  to 

•  Feasibility  studies  and  cost-benefit  analyses  of  upgrading  a  given  ship  to 
MEO  from  GEO. 

•  The  use  of  High  Assurance  Internet  Protocol  Encryption  (HAIPE)  devices 
to  provide  communication  security  over  MEO  SATCOM  connections,  as 
identified  by  Stephens  and  Adams  (2016). 

•  A  cost-benefit  analysis  of  providing  MEO  SATCOM  to  a  geographical 
area  (e.g.,  CENTCOM  area  of  responsibility). 

D.  CONCLUSIONS 

A  video  processing  solution  was  integrated  with  the  TFAAS  satellite  terminal 
over  the  03b  Networks  MEO  satellite  system.  TFAAS  uses  commodity  networking 
equipment,  providing  an  Ethernet  port  for  connection  to  the  customer’s  network.  This 
solution  can  be  used  to  deliver  ultra  high  definition  (UHD)  video  from  forward-deployed 
units  in  a  wide  variety  of  use  cases  and  applications.  The  use  case  studied  in  this  research 
utilized  commodity  digital  camera  and  computing  equipment  to  send  a  live  4K  video 
stream  to  the  Defense  Media  Activity’s  public  video  media  outlet,  DVIDS. 

Commander,  Naval  Air  Forces  Atlantic  Public  Affairs  Office  identified  an 
operational  requirement  for  the  provision  of  video  services  that  could  swiftly  distribute 
high-quality  video  from  within  the  fleet  to  anywhere  in  the  world  with  short  notice.  The 
purpose  of  this  research  was  to  integrate  previously  researched  subsystems  and  to 
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evaluate  their  ability  to  work  together  to  meet  CNAL’s  requirement.  The  On-location 
Public  Affairs  Reach-back  System  (OnPARS)  was  the  result  and  it  was  found  to  provide 
the  necessary  capabilities  to  satisfy  high-quality  video  requirements  of  forward-deployed 
units. 
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APPENDIX  A.  GLOSSARY 


byte 

eight  bits 

color  depth 

refers  to  the  number  of  bits  used  to  describe  colors  within 
an  image 

gigabit 

one  billion  (1,000,000,000)  bits 

gigabyte 

one  billion  (1,000,000,000)  bytes 

megabit 

one  million  (1,000,000)  bits 

megabyte 

one  million  (1,000,000)  bytes 

out-of-the-box 

configuration  of  a  product  when  received  from  the 
publisher  or  manufacturer 

terabyte 

one  trillion  (1,000,000,000)  bytes 
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APPENDIX  B.  DATA 


Table  1.  iPerf3  Mobile  Server  to  NPS  Server  Data 


iperf3  Tool  - 

Mobile  Server  to  Server  at  NPS  -  40-second  Test  Interval 

i 

Sender 

Receiver 

Sender-Receiver 

Variation 

Date 

Time 

Time 

Elapsed 

Transfer 

Bandwidth 

Retr 

Transfer 

Bandwidth 

Transfer 

Bandwidth 

(PDT) 

Since 

Previous 

Time 

(MB) 

(Mbps) 

(MB) 

(Mbps) 

(MB) 

(Mbps) 

Test 

8/11/16 

14:25 

0:00 

0:00 

264 

55.3 

6 

265 

55.6 

i 

0.3 

14:53 

0:28 

0:28 

300 

62.9 

4 

302 

63.4 

2 

0.5 

14:56 

0:03 

0:31 

212 

44.5 

2 

212 

44.5 

0 

0.0 

15:00 

0:04 

0:35 

350 

73.4 

0 

353 

74.0 

3 

0.6 

15:01 

0:01 

0:36 

325 

68.1 

1 

328 

68.7 

3 

0.6 

15:04 

0:03 

0:39 

288 

60.3 

5 

289 

60.6 

1 

0.3 

15:32 

0:28 

1:07 

338 

70.9 

4 

339 

71.1 

1 

0.2 

15:40 

0:08 

1:15 

282 

59.2 

3 

282 

59.2 

0 

0.0 

15:50 

0:10 

1:25 

327 

68.6 

3 

329 

69.0 

2 

0.4 

16:00 

0:10 

1:35 

298 

62.6 

5 

300 

62.8 

2 

0.2 

16:10 

0:10 

1:45 

333 

69.8 

2 

335 

70.3 

2 

0.5 

16:20 

0:10 

1:55 

334 

70.0 

3 

336 

70.4 

2 

0.4 

16:30 

0:10 

2:05 

336 

70.4 

3 

338 

70.8 

2 

0.4 

16:35 

0:05 

2:10 

332 

69.6 

2 

335 

70.2 

3 

0.6 

16:38 

0:03 

2:13 

329 

68.9 

3 

331 

69.4 

2 

0.5 

16:43 

0:05 

2:18 

241 

50.5 

3 

242 

50.9 

1 

0.4 

16:50 

0:07 

2:25 

337 

70.6 

2 

340 

71.2 

3 

0.6 

17:00 

0:10 

2:35 

333 

69.9 

4 

335 

70.2 

2 

0.3 

17:10 

0:10 

2:45 

277 

58.1 

5 

278 

58.4 

1 

0.3 

17:20 

0:10 

2:55 

316 

66.4 

5 

318 

66.7 

2 

0.3 

17:30 

0:10 

3:05 

238 

49.9 

7 

239 

50.1 

1 

0.2 

17:40 

0:10 

3:15 

349 

73.2 

1 

352 

73.8 

3 

0.6 

17:50 

0:10 

3:25 

286 

59.9 

5 

287 

60.2 

1 

0.3 

18:00 

0:10 

3:35 

333 

69.8 

3 

335 

70.2 

2 

0.4 

18:10 

0:10 

3:45 

305 

64.0 

4 

307 

64.3 

2 

0.3 

18:20 

0:10 

3:55 

281 

59.0 

6 

282 

59.2 

1 

0.2 

18:30 

0:10 

4:05 

339 

71.0 

3 

341 

71.6 

2 

0.6 

18:40 

0:10 

4:15 

315 

66.1 

5 

317 

66.4 

2 

0.3 

18:50 

0:10 

4:25 

196 

41.1 

3 

199 

41.6 

3 

0.5 

19:00 

0:10 

4:35 

337 

70.7 

1 

338 

71.0 

1 

0.3 

19:10 

0:10 

4:45 

234 

49.1 

3 

236 

49.4 

2 

0.3 

19:20 

0:10 

4:55 

331 

69.4 

3 

333 

69.8 

2 

0.4 

19:30 

0:10 

5:05 

323 

67.8 

0 

326 

68.4 

3 

0.6 

19:40 

0:10 

5:15 

351 

73.5 

0 

354 

74.1 

3 

0.6 

19:50 

0:10 

5:25 

322 

67.5 

3 

324 

67.9 

2 

0.4 

20:00 

0:10 

5:35 

350 

73.5 

0 

353 

74.1 

3 

0.6 

20:10 

0:10 

5:45 

307 

64.4 

4 

308 

64.6 

1 

0.2 

20:20 

0:10 

5:55 

287 

60.2 

1 

288 

60.4 

1 

0.2 

20:36 

0:16 

6:11 

339 

71.1 

3 

341 

71.6 

2 

0.5 

20:40 

0:04 

6:15 

336 

70.4 

4 

337 

70.7 

1 

0.3 

20:46 

0:06 

6:21 

322 

67.4 

4 

323 

67.8 

1 

0.4 

20:50 

0:04 

6:25 

272 

56.9 

3 

273 

57.3 

1 

0.4 

21:00 

0:10 

6:35 

283 

59.5 

7 

285 

59.7 

2 

0.2 

21:10 

0:10 

6:45 

340 

71.2 

3 

341 

71.6 

1 

0.4 

21:20 

0:10 

6:55 

332 

69.6 

3 

334 

70.1 

2 

0.5 

21:30 

0:10 

7:05 

230 

48.2 

4 

231 

48.5 

1 

0.3 

21:40 

0:10 

7:15 

338 

70.9 

3 

341 

71.4 

3 

0.5 

21:50 

0:10 

7:25 

322 

67.5 

3 

324 

67.9 

2 

0.4 

22:00 

0:10 

7:35 

137 

28.6 

9 

137 

28.8 

0 

0.2 

22:10 

0:10 

7:45 

336 

70.5 

2 

339 

71.0 

3 

0.5 

22:20 

0:10 

7:55 

351 

73.5 

0 

353 

74.1 

2 

0.6 

22:30 

0:10 

8:05 

244 

51.2 

1 

247 

51.8 

3 

0.6 

22:40 

0:10 

8:15 

325 

68.2 

3 

328 

68.8 

3 

0.6 

22:50 

0:10 

8:25 

344 

72.2 

2 

344 

72.2 

0 

0.0 

23:00 

0:10 

8:35 

344 

72.1 

1 

346 

72.6 

2 

0.5 

23:10 

0:10 

8:45 

263 

55.1 

6 

264 

55.4 

1 

0.3 

23:20 

0:10 

8:55 

328 

68.8 

2 

331 

69.4 

3 

0.6 
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iperf3  Tool  -  Mobile  Server  to  Server  at  NPS  -  40-second  Test  Interval _ _ 

Sender  Receiver  Sender-Receiver 

Variation 


Date 

Time 

(PDT) 

Time 

Since 

Previous 

Test 

Elapsed 

Time 

Transfer 

(MB) 

Bandwidth 

(Mbps) 

Retr 

Transfer 

(MB) 

Bandwidth 

(Mbps) 

Transfer 

(MB) 

Bandwidth 

(Mbps) 

23:30 

0:10 

9:05 

339 

71.1 

1 

342 

71.8 

3 

0.7 

23:40 

0:10 

9:15 

304 

63.7 

2 

307 

64.3 

3 

0.6 

23:50 

0:10 

9:25 

305 

64.0 

4 

307 

64.3 

2 

0.3 

8/12/16 

0:00 

0:10 

9:35 

336 

70.4 

2 

338 

70.9 

2 

0.5 

0:10 

0:10 

9:45 

340 

71.2 

2 

342 

71.8 

2 

0.6 

0:20 

0:10 

9:55 

338 

70.8 

1 

341 

71.5 

3 

0.7 

0:30 

0:10 

10:05 

351 

73.7 

0 

354 

74.3 

3 

0.6 

0:40 

0:10 

10:15 

338 

70.9 

1 

341 

71.5 

3 

0.6 

0:50 

0:10 

10:25 

338 

70.9 

2 

341 

71.5 

3 

0.6 

1:00 

0:10 

10:35 

351 

73.5 

0 

353 

74.1 

2 

0.6 

1:10 

0:10 

10:45 

351 

73.6 

0 

354 

74.2 

3 

0.6 

1:20 

0:10 

10:55 

339 

71.2 

1 

342 

71.8 

3 

0.6 

1:30 

0:10 

11:05 

351 

73.5 

0 

354 

74.2 

3 

0.7 

1:40 

0:10 

11:15 

325 

68.1 

3 

327 

68.6 

2 

0.5 

1:50 

0:10 

11:25 

351 

73.6 

0 

354 

74.2 

3 

0.6 

2:00 

0:10 

11:35 

351 

73.5 

0 

354 

74.2 

3 

0.7 

2:10 

0:10 

11:45 

338 

71.0 

1 

341 

71.6 

3 

0.6 

2:20 

0:10 

11:55 

351 

73.6 

0 

354 

74.2 

3 

0.6 

2:30 

0:10 

12:05 

350 

73.5 

0 

353 

74.1 

3 

0.6 

2:40 

0:10 

12:15 

351 

73.5 

0 

353 

74.1 

2 

0.6 

2:50 

0:10 

12:25 

351 

73.5 

0 

353 

74.1 

2 

0.6 

3:00 

0:10 

12:35 

343 

71.9 

1 

346 

72.5 

3 

0.6 

3:10 

0:10 

12:45 

352 

73.7 

0 

354 

74.3 

2 

0.6 

3:20 

0:10 

12:55 

344 

72.2 

1 

346 

72.7 

2 

0.5 

3:30 

0:10 

13:05 

326 

68.4 

3 

328 

68.7 

2 

0.3 

3:40 

0:10 

13:15 

351 

73.5 

0 

354 

74.2 

3 

0.7 

3:50 

0:10 

13:25 

351 

73.6 

0 

354 

74.2 

3 

0.6 

4:00 

0:10 

13:35 

351 

73.7 

0 

354 

74.3 

3 

0.6 

4:10 

0:10 

13:45 

351 

73.5 

0 

354 

74.1 

3 

0.6 

4:20 

0:10 

13:55 

351 

73.6 

0 

354 

74.2 

3 

0.6 

4:30 

0:10 

14:05 

283 

59.3 

1 

283 

59.4 

0 

0.1 

4:40 

0:10 

14:15 

338 

70.9 

1 

341 

71.5 

3 

0.6 

4:50 

0:10 

14:25 

351 

73.5 

0 

354 

74.1 

3 

0.6 

5:00 

0:10 

14:35 

339 

71.1 

1 

342 

71.7 

3 

0.6 

5:10 

0:10 

14:45 

339 

71.2 

1 

342 

71.8 

3 

0.6 

5:20 

0:10 

14:55 

333 

69.9 

3 

336 

70.5 

3 

0.6 

5:30 

0:10 

15:05 

351 

73.5 

0 

354 

74.1 

3 

0.6 

5:40 

0:10 

15:15 

333 

69.9 

2 

335 

70.3 

2 

0.4 

6:00 

0:20 

15:35 

319 

66.9 

3 

322 

67.5 

3 

0.6 

6:10 

0:10 

15:45 

351 

73.7 

0 

354 

74.3 

3 

0.6 

6:20 

0:10 

15:55 

280 

58.8 

4 

282 

59.2 

2 

0.4 

6:30 

0:10 

16:05 

335 

70.4 

2 

337 

70.8 

2 

0.4 

6:40 

0:10 

16:15 

337 

70.8 

1 

340 

71.4 

3 

0.6 

6:50 

0:10 

16:25 

323 

67.6 

4 

324 

68.0 

1 

0.4 

7:00 

0:10 

16:35 

329 

69.1 

3 

332 

69.6 

3 

0.5 

7:10 

0:10 

16:45 

350 

73.4 

0 

353 

74.0 

3 

0.6 

7:20 

0:10 

16:55 

291 

61.0 

4 

292 

61.3 

1 

0.3 

7:30 

0:10 

17:05 

351 

73.6 

0 

354 

74.2 

3 

0.6 

7:40 

0:10 

17:15 

340 

71.4 

2 

343 

71.8 

3 

0.4 

7:50 

0:10 

17:25 

351 

73.6 

0 

354 

74.2 

3 

0.6 

8:00 

0:10 

17:35 

330 

69.3 

2 

331 

69.3 

1 

0.0 

8:10 

0:10 

17:45 

326 

68.4 

2 

329 

68.9 

3 

0.5 

8:20 

0:10 

17:55 

337 

70.7 

1 

340 

71.3 

3 

0.6 

Sender 

Receiver 

Sender-Receiver 

Variation 

Transfer 

(MB) 

Bandwidth 

(Mbps) 

Retr 

Transfer 

(MB) 

Bandwidth 

(Mbps) 

Transfer 

(MB) 

Bandwidth 

(Mbps) 

Min 

137 

28.6 

0 

137 

28.8 

0 

0.0 

Max 

352 

73.7 

9 

354 

74.3 

3 

0.7 

Average 

321 

67.3 

2 

323 

67.8 

2 

0.5 

Median 

335.5 

70.4 

2 

337 

70.8 

2 

0.5 
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Table  2.  iPerf3  NPS  Server  to  Mobile  Server  Data 


iperf3  Tool  -  Server  at  NPS  to  Mobile  Server  -  40-second  Test  Interval 


Sender 

Receiver 

Sender-Receiver 

Variation 

Date 

Time 

Time 

Elapsed 

Transfer 

Bandwidth 

Retr 

Transfer 

Bandwidth 

Transfer 

Bandwidth 

(PDT) 

Since 

Previous 

Time 

(MB) 

(Mbps) 

(MB) 

(Mbps) 

(MB) 

(Mbps) 

Test 

8/11/16 

14:26 

0:00 

0:00 

138 

29.0 

170 

138 

29.0 

0 

0.0 

14:54 

0:28 

0:28 

227 

47.7 

145 

228 

47.8 

1 

0.1 

14:56 

0:02 

0:30 

229 

48.1 

119 

229 

48.1 

0 

0.0 

15:00 

0:04 

0:34 

231 

48.4 

81 

230 

48.3 

1 

0.1 

15:04 

0:04 

0:38 

249 

52.3 

5 

248 

52.1 

1 

0.2 

15:33 

0:29 

1:07 

168 

35.3 

104 

169 

35.3 

1 

0.0 

15:40 

0:07 

1:14 

260 

54.4 

112 

258 

54.1 

2 

0.3 

15:50 

0:10 

1:24 

158 

33.2 

123 

159 

33.4 

1 

0.2 

16:00 

0:10 

1:34 

204 

42.8 

306 

203 

42.7 

1 

0.1 

16:10 

0:10 

1:44 

258 

54.1 

68 

258 

54.0 

0 

0.1 

16:20 

0:10 

1:54 

185 

38.9 

117 

186 

38.9 

1 

0.0 

16:36 

0:16 

2:10 

231 

48.5 

109 

232 

48.6 

1 

0.1 

16:43 

0:07 

2:17 

203 

42.5 

47 

203 

42.5 

0 

0.0 

16:50 

0:07 

2:24 

305 

63.9 

0 

304 

63.8 

1 

0.1 

17:00 

0:10 

2:34 

300 

62.8 

0 

300 

62.9 

0 

0.1 

17:10 

0:10 

2:44 

238 

49.9 

114 

238 

49.8 

0 

0.1 

17:20 

0:10 

2:54 

304 

63.8 

0 

304 

63.8 

0 

0.0 

17:30 

0:10 

3:04 

238 

49.9 

143 

238 

49.9 

0 

0.0 

17:40 

0:10 

3:14 

173 

36.4 

121 

173 

36.4 

0 

0.0 

17:50 

0:10 

3:24 

301 

63.1 

0 

301 

63.1 

0 

0.0 

18:00 

0:10 

3:34 

305 

63.9 

0 

304 

63.8 

1 

0.1 

18:10 

0:10 

3:44 

305 

63.9 

0 

304 

63.8 

1 

0.1 

18:20 

0:10 

3:54 

256 

53.7 

98 

256 

53.8 

0 

0.1 

18:30 

0:10 

4:04 

301 

63.1 

0 

301 

63.2 

0 

0.1 

18:40 

0:10 

4:14 

178 

37.4 

159 

179 

37.6 

1 

0.2 

18:50 

0:10 

4:24 

305 

63.9 

0 

304 

63.8 

1 

0.1 

19:00 

0:10 

4:34 

300 

62.8 

0 

300 

62.8 

0 

0.0 

19:10 

0:10 

4:44 

163 

34.3 

132 

164 

34.4 

1 

0.1 

19:20 

0:10 

4:54 

176 

36.8 

129 

175 

36.7 

1 

0.1 

19:30 

0:10 

5:04 

226 

47.5 

282 

226 

47.3 

0 

0.2 

19:40 

0:10 

5:14 

190 

39.8 

156 

191 

40.0 

1 

0.2 

19:50 

0:10 

5:24 

263 

55.1 

0 

263 

55.1 

0 

0.0 

20:00 

0:10 

5:34 

170 

35.7 

160 

172 

36.0 

2 

0.3 

20:10 

0:10 

5:44 

203 

42.5 

65 

202 

42.5 

1 

0.0 

20:34 

0:24 

6:08 

266 

55.7 

0 

266 

55.8 

0 

0.1 

20:37 

0:03 

6:11 

303 

63.6 

0 

303 

63.6 

0 

0.0 

20:40 

0:03 

6:14 

234 

49.2 

131 

235 

49.2 

1 

0.0 

20:47 

0:07 

6:21 

306 

64.1 

0 

305 

64.0 

1 

0.1 

20:51 

0:04 

6:25 

193 

40.4 

100 

192 

40.3 

1 

0.1 

21:01 

0:10 

6:35 

209 

43.9 

190 

210 

44.0 

1 

0.1 

21:11 

0:10 

6:45 

268 

56.3 

0 

269 

56.4 

1 

0.1 

21:21 

0:10 

6:55 

238 

50.0 

171 

238 

49.9 

0 

0.1 

21:31 

0:10 

7:05 

304 

63.9 

0 

304 

63.8 

0 

0.1 

21:41 

0:10 

7:15 

299 

62.8 

0 

300 

62.8 

1 

0.0 

21:51 

0:10 

7:25 

219 

45.9 

17 

220 

46.1 

1 

0.2 

22:01 

0:10 

7:35 

304 

63.9 

0 

305 

63.9 

1 

0.0 

22:11 

0:10 

7:45 

304 

63.8 

0 

304 

63.8 

0 

0.0 

22:21 

0:10 

7:55 

220 

46.1 

4 

221 

46.4 

1 

0.3 

22:31 

0:10 

8:05 

301 

63.1 

0 

301 

63.2 

0 

0.1 

22:41 

0:10 

8:15 

260 

54.5 

84 

260 

54.5 

0 

0.0 

22:51 

0:10 

8:25 

303 

63.6 

0 

304 

63.8 

1 

0.2 

23:01 

0:10 

8:35 

267 

56.0 

94 

267 

55.9 

0 

0.1 

23:11 

0:10 

8:45 

302 

63.4 

0 

301 

63.2 

1 

0.2 

23:21 

0:10 

8:55 

305 

63.9 

0 

304 

63.8 

1 

0.1 

23:31 

0:10 

9:05 

293 

61.3 

93 

292 

61.3 

1 

0.0 

23:41 

0:10 

9:15 

232 

48.6 

61 

232 

48.6 

0 

0.0 

23:51 

0:10 

9:25 

257 

53.8 

114 

257 

53.9 

0 

0.1 

8/12/16 

0:01 

0:10 

9:35 

268 

56.3 

88 

267 

56.0 

1 

0.3 

0:11 

0:10 

9:45 

270 

56.5 

58 

268 

56.3 

2 

0.2 

0:21 

0:10 

9:55 

234 

49.2 

82 

234 

49.1 

0 

0.1 

0:31 

0:10 

10:05 

302 

63.3 

0 

301 

63.2 

1 

0.1 

0:41 

0:10 

10:15 

260 

54.6 

68 

260 

54.6 

0 

0.0 

1:01 

0:20 

10:35 

300 

62.8 

0 

300 

62.8 

0 

0.0 
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iperf3  Tool  -  Server  at  NPS  to  Mobile  Server  -  40-second  Test  Interval 


Sender 

Receiver 

Sender-Receiver 

Variation 

Date  Time 

Time 

Elapsed 

Transfer 

Bandwidth 

Retr 

Transfer 

Bandwidth 

Transfer 

Bandwidth 

(PDT) 

Since 

Previous 

Time 

(MB) 

(Mbps) 

(MB) 

(Mbps) 

(MB) 

(Mbps) 

Test 

1:11 

0:10 

10:45 

299 

62.8 

0 

299 

62.7 

0 

0.1 

1:21 

0:10 

10:55 

304 

63.9 

0 

304 

63.7 

0 

0.2 

1:31 

0:10 

11:05 

275 

57.6 

0 

274 

57.5 

1 

0.1 

1:41 

0:10 

11:15 

302 

63.4 

0 

301 

63.1 

1 

0.3 

1:51 

0:10 

11:25 

301 

63.1 

0 

301 

63.2 

0 

0.1 

2:01 

0:10 

11:35 

303 

63.6 

0 

304 

63.8 

1 

0.2 

2:11 

0:10 

11:45 

305 

63.9 

0 

304 

63.8 

1 

0.1 

2:21 

0:10 

11:55 

292 

61.2 

2 

293 

61.4 

1 

0.2 

2:31 

0:10 

12:05 

292 

61.2 

26 

291 

61.0 

1 

0.2 

2:41 

0:10 

12:15 

304 

63.9 

0 

304 

63.8 

0 

0.1 

2:51 

0:10 

12:25 

304 

63.9 

0 

304 

63.8 

0 

0.1 

3:01 

0:10 

12:35 

301 

63.1 

0 

300 

62.9 

1 

0.2 

3:11 

0:10 

12:45 

302 

63.3 

0 

301 

63.2 

1 

0.1 

3:21 

0:10 

12:55 

304 

63.9 

0 

304 

63.8 

0 

0.1 

3:31 

0:10 

13:05 

305 

63.9 

0 

304 

63.8 

1 

0.1 

3:41 

0:10 

13:15 

300 

62.8 

0 

300 

62.8 

0 

0.0 

3:51 

0:10 

13:25 

301 

63.1 

0 

301 

63.2 

0 

0.1 

4:01 

0:10 

13:35 

299 

62.8 

3 

299 

62.8 

0 

0.0 

4:11 

0:10 

13:45 

304 

63.8 

0 

304 

63.8 

0 

0.0 

4:21 

0:10 

13:55 

300 

62.8 

0 

300 

62.8 

0 

0.0 

4:31 

0:10 

14:05 

301 

63.1 

0 

301 

63.2 

0 

0.1 

4:41 

0:10 

14:15 

304 

63.8 

0 

304 

63.8 

0 

0.0 

4:51 

0:10 

14:25 

299 

62.8 

6 

300 

62.9 

1 

0.1 

5:01 

0:10 

14:35 

294 

61.7 

7 

294 

61.7 

0 

0.0 

5:11 

0:10 

14:45 

252 

53.0 

62 

253 

53.1 

1 

0.1 

5:21 

0:10 

14:55 

305 

63.9 

0 

304 

63.8 

1 

0.1 

5:31 

0:10 

15:05 

303 

63.6 

0 

304 

63.8 

1 

0.2 

5:41 

0:10 

15:15 

300 

62.8 

0 

300 

62.9 

0 

0.1 

5:52 

0:11 

15:26 

302 

63.4 

0 

302 

63.4 

0 

0.0 

6:01 

0:09 

15:35 

196 

41.1 

58 

197 

41.3 

1 

0.2 

6:11 

0:10 

15:45 

260 

54.5 

75 

260 

54.6 

0 

0.1 

6:21 

0:10 

15:55 

218 

45.7 

96 

218 

45.7 

0 

0.0 

6:31 

0:10 

16:05 

273 

57.2 

99 

273 

57.2 

0 

0.0 

6:41 

0:10 

16:15 

306 

64.1 

0 

306 

64.1 

0 

0.0 

6:51 

0:10 

16:25 

305 

63.9 

0 

304 

63.8 

1 

0.1 

7:01 

0:10 

16:35 

300 

62.8 

0 

300 

62.9 

0 

0.1 

7:11 

0:10 

16:45 

214 

44.9 

29 

214 

44.9 

0 

0.0 

7:21 

0:10 

16:55 

277 

58.2 

0 

278 

58.3 

1 

0.1 

7:31 

0:10 

17:05 

306 

64.1 

0 

305 

64.0 

1 

0.1 

7:41 

0:10 

17:15 

302 

63.3 

0 

302 

63.3 

0 

0.0 

7:51 

0:10 

17:25 

185 

38.8 

203 

185 

38.7 

0 

0.1 

8:01 

0:10 

17:35 

260 

54.6 

84 

260 

54.5 

0 

0.1 

8:11 

0:10 

17:45 

305 

63.9 

0 

304 

63.8 

1 

0.1 

8:21 

0:10 

17:55 

256 

53.8 

107 

258 

54.0 

2 

0.2 

Sender 

Receiver 

Sender-Receiver 

Variation 

Transfer 

Bandwidth 

Retr 

Transfer 

Bandwidth 

Transfer 

Bandwidth 

(MB) 

(Mbps) 

(MB) 

(Mbps) 

(MB) 

(Mbps) 

Min 

138 

29.0 

0 

138 

29.0 

0 

0.0 

Max 

306 

64.1 

306 

306 

64.1 

2 

0.3 

Average 

265 

55.6 

49 

265 

55.6 

1 

0.1 

Median 

292 

61.2 

0 

292 

61.3 

1 

0.1 
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Table  3.  Ping  Mobile  Server  to  Google’s  DNS  Data 


ping  Tool  - 

Mobile  Server  to  Google's  DNS  (8.8.8.8)  - 

10-pings  Round  Trip  Time 

Date 

Time 

(PDT) 

Time  Since  Previous 
Test 

Elapsed 

Time 

Min 

Avg 

Max 

Mdev 

8/11/16 

20:46 

0:00 

0:00 

156.529 

156.560 

156.610 

0.178 

20:50 

0:04 

0:04 

156.762 

156.813 

156.857 

0.501 

21:00 

0:10 

0:14 

159.226 

159.455 

159.533 

0.265 

21:10 

0:10 

0:24 

159.915 

159.957 

160.018 

0.537 

21:20 

0:10 

0:34 

156.917 

156.965 

157.005 

0.307 

21:30 

0:10 

0:44 

156.793 

156.831 

156.886 

0.179 

21:40 

0:10 

0:54 

159.521 

159.577 

159.623 

0.400 

21:50 

0:10 

1:04 

159.729 

159.883 

160.775 

0.300 

22:00 

0:10 

1:14 

156.861 

156.893 

156.936 

0.501 

22:10 

0:10 

1:24 

156.836 

156.884 

156.926 

0.355 

22:20 

0:10 

1:34 

159.731 

159.755 

159.781 

0.179 

22:30 

0:10 

1:44 

160.039 

160.099 

160.150 

0.312 

22:40 

0:10 

1:54 

156.951 

156.978 

157.046 

0.251 

22:50 

0:10 

2:04 

156.709 

156.747 

156.789 

0.178 

23:00 

0:10 

2:14 

159.126 

159.371 

159.448 

0.512 

23:10 

0:10 

2:24 

160.057 

160.116 

160.212 

0.507 

23:20 

0:10 

2:34 

156.985 

157.027 

157.070 

0.252 

23:30 

0:10 

2:44 

156.761 

156.803 

156.836 

0.531 

23:40 

0:10 

2:54 

159.420 

159.477 

159.512 

0.358 

23:50 

0:10 

3:04 

160.298 

160.334 

160.391 

0.507 

1  8/12/16 

0:00 

0:10 

3:14 

156.716 

157.077 

157.161 

0.216 

0:10 

0:10 

3:24 

156.680 

156.716 

156.744 

0.019 

0:20 

0:10 

3:34 

159.160 

159.215 

159.261 

0.310 

0:30 

0:10 

3:44 

159.935 

160.000 

160.097 

0.475 

0:40 

0:10 

3:54 

156.920 

156.966 

157.025 

0.179 

0:50 

0:10 

4:04 

156.812 

156.835 

156.887 

0.396 

1:00 

0:10 

4:14 

159.473 

159.546 

159.607 

0.474 

1:10 

0:10 

4:24 

161.149 

161.243 

161.318 

0.259 

1:20 

0:10 

4:34 

157.484 

157.551 

157.608 

0.470 

1:30 

0:10 

4:44 

156.629 

156.679 

156.729 

0.252 

1:40 

0:10 

4:54 

158.653 

158.688 

158.721 

0.019 

1:50 

0:10 

5:04 

159.831 

160.088 

160.164 

0.369 

2:00 

0:10 

5:14 

156.978 

157.001 

157.019 

0.307 

2:10 

0:10 

5:24 

156.714 

156.733 

156.770 

0.531 

2:20 

0:10 

5:34 

159.306 

159.377 

159.460 

0.440 

2:30 

0:10 

5:44 

160.062 

160.124 

160.181 

0.401 

2:40 

0:10 

5:54 

156.913 

156.975 

157.002 

0.178 

2:50 

0:10 

6:04 

156.679 

156.723 

156.770 

0.397 

3:00 

0:10 

6:14 

159.304 

159.344 

159.396 

0.310 

3:10 

0:10 

6:24 

159.894 

159.939 

160.033 

0.538 

3:20 

0:10 

6:34 

156.890 

156.918 

156.947 

0.501 

3:30 

0:10 

6:44 

156.737 

156.782 

156.821 

0.434 

3:40 

0:10 

6:54 

159.434 

159.487 

159.541 

0.311 

3:50 

0:10 

7:04 

159.710 

159.754 

159.861 

0.255 

4:00 

0:10 

7:14 

156.782 

156.813 

156.859 

0.355 

4:10 

0:10 

7:24 

156.755 

156.793 

156.823 

0.307 

4:20 

0:10 

7:34 

159.556 

159.632 

159.682 

0.311 

4:30 

0:10 

7:44 

159.619 

159.998 

160.141 

0.463 

4:40 

0:10 

7:54 

156.866 

156.920 

156.973 

0.469 
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ping  Tool  - 

Mobile  Server  to  Google's  DNS  (8.8.8.8)  - 

10-pings  Round  Trip  Time 

Date 

Time 

(PDT) 

Time  Since  Previous 
Test 

Elapsed 

Time 

Min 

Avg 

Max 

Mdev 

4:50 

0:10 

8:04 

156.655 

156.705 

156.733 

0.178 

5:00 

0:10 

8:14 

159.316 

159.358 

159.405 

0.438 

5:10 

0:10 

8:24 

160.061 

160.115 

160.158 

0.254 

5:20 

0:10 

8:34 

156.946 

156.976 

157.013 

0.396 

5:30 

0:10 

8:44 

156.654 

156.698 

156.741 

0.531 

5:40 

0:10 

8:54 

158.920 

159.277 

159.349 

0.417 

5:50 

0:10 

9:04 

160.197 

160.275 

160.392 

0.054 

6:00 

0:10 

9:14 

156.548 

156.960 

157.059 

0.420 

6:10 

0:10 

9:24 

156.569 

156.636 

156.801 

0.534 

6:20 

0:10 

9:34 

159.046 

159.122 

159.196 

0.439 

6:30 

0:10 

9:44 

159.436 

159.880 

160.210 

0.473 

6:40 

0:10 

9:54 

156.786 

156.834 

156.869 

0.307 

6:50 

0:10 

10:04 

156.648 

156.677 

156.697 

0.016 

7:00 

0:10 

10:14 

159.357 

159.400 

159.473 

0.182 

7:10 

0:10 

10:24 

161.080 

161.155 

161.265 

0.364 

7:20 

0:10 

10:34 

157.323 

157.379 

157.420 

0.397 

7:30 

0:10 

10:44 

156.426 

156.481 

156.521 

0.501 

7:40 

0:10 

10:54 

158.394 

158.459 

158.526 

0.039 

7:50 

0:10 

11:04 

159.968 

160.012 

160.068 

0.474 

8:00 

0:10 

11:14 

156.808 

156.844 

156.889 

0.026 

8:10 

0:10 

11:24 

156.565 

156.613 

156.679 

0.356 

8:20 

0:10 

11:34 

159.199 

159.252 

159.314 

0.505 

Min 

156.426 

156.481 

156.521 

0.016 

Max 

161.149 

161.243 

161.318 

0.538 

Average 

158.193 

158.275 

158.349 

0.343 

Median 

157.484 

157.551 

157.608 

0.358 
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Table  4.  iPerf  Mobile  Server  to  03b  Hub  TCP  Mode  Data 


iperf  Tool  -  TCP  Connection  from 

Mobile  Server  to  03b  Hub, 

Vernon,  Tx 

Date 

Time 

(PDT) 

Time  Since 
Previous  Test 

Elapsed 

Time 

Transfer 

(MB) 

Bandwidth 

(Mbps) 

8/11/16 

16:44 

0:00 

0:00 

253 

70.6 

16:51 

0:07 

0:07 

254 

70.7 

17:01 

0:10 

0:17 

252 

70.5 

17:11 

0:10 

0:27 

252 

70.4 

17:21 

0:10 

0:37 

253 

70.7 

17:31 

0:10 

0:47 

251 

70.0 

17:41 

0:10 

0:57 

253 

70.4 

17:51 

0:10 

1:07 

251 

70.2 

18:01 

0:10 

1:17 

238 

66.1 

18:11 

0:10 

1:27 

253 

70.3 

18:21 

0:10 

1:37 

246 

68.8 

18:31 

0:10 

1:47 

250 

69.9 

18:41 

0:10 

1:57 

254 

70.7 

18:51 

0:10 

2:07 

251 

70.1 

19:01 

0:10 

2:17 

253 

70.5 

19:11 

0:10 

2:27 

247 

68.9 

19:21 

0:10 

2:37 

252 

70.3 

19:31 

0:10 

2:47 

231 

64.4 

19:41 

0:10 

2:57 

253 

70.4 

19:51 

0:10 

3:07 

206 

57.3 

Min 

206 

57.3 

Max 

254 

70.7 

Average 

248 

69.1 

Median 

252 

70.3 
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Table  5.  iPerf  Mobile  Server  to  03b  Hub  UDP  Mode  Data 


iperf  Tool  -  UDP  Connectior 

(C 

l  from  Mobile  Server  to  03b  Hub,  Vernon,  Tx  -  Server 
)3b  Hub)  Reported  Statistics 

Date 

Time 

(PDT) 

Time 

Since 

Previous 

Test 

Elapsed 

Time 

Transfer 

(MB) 

Bandwidth 

(Mbps) 

Jitter 

(ms) 

Datagram 

Loss 

8/11/16 

16:52 

0:00 

0:00 

270 

74.7 

0.185 

24% 

17:02 

0:10 

0:10 

271 

74.9 

0.217 

24% 

17:12 

0:10 

0:20 

271 

74.9 

0.210 

24% 

17:22 

0:10 

0:30 

270 

74.6 

0.190 

24% 

17:32 

0:10 

0:40 

270 

74.6 

0.182 

24% 

17:42 

0:10 

0:50 

270 

74.6 

0.233 

24% 

17:52 

0:10 

1:00 

271 

74.9 

0.197 

24% 

18:02 

0:10 

1:10 

270 

74.3 

0.311 

25% 

18:12 

0:10 

1:20 

270 

74.7 

0.213 

24% 

18:22 

0:10 

1:30 

270 

74.8 

0.193 

24% 

18:32 

0:10 

1:40 

270 

74.5 

0.264 

25% 

18:42 

0:10 

1:50 

270 

74.6 

0.195 

24% 

18:52 

0:10 

2:00 

270 

74.8 

0.197 

24% 

19:02 

0:10 

2:10 

271 

74.8 

0.240 

24% 

19:12 

0:10 

2:20 

271 

74.8 

0.214 

24% 

19:22 

0:10 

2:30 

270 

74.9 

0.199 

24% 

19:32 

0:10 

2:40 

270 

74.5 

0.195 

24% 

19:42 

0:10 

2:50 

270 

74.8 

0.229 

24% 

19:52 

0:10 

3:00 

270 

74.5 

0.242 

24% 

20:01 

0:09 

3:09 

271 

74.8 

0.187 

24% 

20:11 

0:10 

3:19 

271 

74.8 

0.253 

24% 

20:20 

0:09 

3:28 

271 

74.9 

0.187 

24% 

20:34 

0:14 

3:42 

271 

74.8 

0.214 

24% 

20:38 

0:04 

3:46 

272 

74.9 

0.201 

24% 

20:41 

0:03 

3:49 

271 

74.8 

0.230 

24% 

20:48 

0:07 

3:56 

271 

74.8 

0.208 

24% 

Min 

270 

74 

0.182 

24% 

Max 

272 

75 

0.311 

25% 

Average 

271 

75 

0.215 

24% 

Median 

270 

75 

0.209 

24% 
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Table  6.  IPTraf  Streaming  Capture  Data 


iptraf  - 

60-second  Video  Streaming  Capture 

Average  (kbps) 

Peak  (kbps) 

Date 

Time 

(PDT) 

Outgoing 

Incoming 

Total 

Outgoing 

Incoming 

Total 

8/11/16 

11:55 

439.92 

7.68 

447.62 

479.38 

8.32 

487.70 

12:20 

1166.47 

18.47 

1184.95 

3414.40 

55.62 

3463.05 

12:35 

462.97 

157.52 

620.50 

534.34 

416.92 

923.88 

13:34 

404.98 

9.10 

414.08 

408.44 

9.37 

417.56 

13:39 

1205.52 

17.53 

1223.05 

1869.64 

29.78 

1894.07 

13:49 

477.00 

49.45 

526.45 

552.16 

377.49 

849.45 

13:50 

442.83 

7.45 

450.30 

503.00 

8.70 

511.69 

13:52 

459.22 

58.37 

517.58 

549.73 

220.35 

646.32 

14:03 

562.38 

64.83 

627.22 

635.41 

435.45 

1021.20 

Min 

404.98 

7.45 

414.08 

408.44 

8.32 

417.56 

Max 

1205.52 

157.52 

1223.05 

3414.40 

435.45 

3463.05 

Average 

624.59 

43.38 

667.97 

994.06 

173.56 

1134.99 

Median 

462.97 

18.47 

526.45 

549.73 

55.62 

849.45 
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